4 ms·
Is that a good or bad thing? What’s the trade-off being made here?
by stingraycharles 5y ago
Is that a good or bad thing? What’s the trade-off being made here?
- 5e92cb50239222b 5y agohttps://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
- vips7L 5y agoThat article is beyond out of date when it comes to Java GC.
- throwaway894345 5y agoCompacting GC tends to have cheaper allocs and longer pauses (allocs need to be moved to different regions of memory and pointers to those allocs need to be rewritten to point to the new memory regions) while noncompacting has the opposite: slow allocations and small pause times.
- kaba0 5y agoThough many part of compaction can be moved to a parallel thread, can’t it? The actual stop-the-world time can be quite small that way (using read-barriers though)
- throwaway894345 5y agoI’m not so sure about barriers, but compacting requires rewriting pointers that are shared with the mutator threads, so it seems hard to parallelize.
- kaba0 5y agoAs far as I know, this is the “secret” of ZGC at least, it replaces the usual write barriers with read ones. So a parallel thread is free to move an object to a new place, and any thread trying to access it will at that point lock said object. This will have a performance impact (the usual write barriers have better throughput because they only “lock” when writing an object), but more of the GC can be parallelized. But I’m by no means anywhere close to an expert in the topic.
- throwaway894345 5y agoInteresting. What about an application thread (“mutator” in GC parlance) that tries to write to the pointer? Does that hit the read barrier as well? Does this imply worse application throughout to improve GC metrics? If so, I wonder how much worse? (Not asking you per se, but wondering aloud)