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.
-
Show 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 -
Replying to @noop_dev
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.
1 reply 0 retweets 1 like -
Replying to @TimSweeneyEpic
Sorry, but after messing a bit with JVM and with .NET I don’t see this happening in near future. VMs already appear to be full of hacky opts to have decent perf on the current archs and reduce GC frequency. They seem to become more and more bogged down by all that complexity.
1 reply 0 retweets 0 likes -
Replying to @noop_dev @TimSweeneyEpic
Making GC not suck is hard, hence why my efforts mostly gave up on it. Some tricks to make GC less bad can be made explicit and combined with a manual MM general case (say, "new!" means "this object has an automatic lifetime", giving error if the object goes out of scope, ...).
1 reply 0 retweets 1 like -
Replying to @cr88192 @TimSweeneyEpic
As I suspect, existing VM JIT impls already try to pin data to scope(possible stack alloc), then to thread (TLS alloc, simplified GC) before giving up an putting it into the common heap.
1 reply 0 retweets 1 like -
Essentially, they do. Stack alloc = bump heap, escape analysis here and there, generations, and hacks upon hacks after a lot of testing. An idealized GC is indeed impossibly hard to devise, esp. with the limited tools / primitives provided by OS and CPU.
1 reply 0 retweets 1 like -
And then there's C++. I did try to sketch one once. Generic, reusable, relocating and a bunch of other properties. It was a mistake to mix these two. But then they were also interdependent... Eh.
2 replies 0 retweets 0 likes -
... But something manageable is still possible if you are to specialize. :)https://github.com/hsutter/gcpp
1 reply 0 retweets 0 likes -
That solution is hardly a general-purpose GC though.
1 reply 0 retweets 0 likes
My hypothesis: As core counts increase, developer tolerance for GC overhead will rise, but tolerance for GC pauses will fall. Thus I’m comfortable with overhead as long as GC is completely nonblocking.
-
Show additional replies, including those that may contain offensive content
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.