After 3 months of coding weekends, my attempt to create a relocating nonblocking garbage collector in C++ has failed. It works in theory, but in practice the read barrier is pervasive and costly, and the threading invariants are incredibly tricky to maintain.
-
Show this thread
-
Now I see why the best relocating collectors, like Microsoft's for .NET, "stop the world" at critical times. That's not workable in general C++ code though, and won't scale to many-core. Conclusion: A non-relocating concurrent garbage collector will be optimal.
11 replies 10 retweets 65 likesShow this thread -
Replying to @TimSweeneyEpic
Some years ago it became quite clear to me, that GC is not designed for shared-memory multithreading, at least if you want any realtime guarantees. And if you try writing low-garbage/garbage-free code in Java, it becomes way more tedious and restrictive than C.
2 replies 0 retweets 0 likes
All the leading GCs were designed for a small number of cores or applications where some pauses were acceptable. I’m optimistic a new GC can be developed that scales well to many-core, is non-blocking, and minimizes contention.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.