3 ms·

As far as I can tell, the JVM GC is (not surprisingly) significantly more mature. The JVM has a concurrent mark-sweep algorithm that works similarly to what's

As far as I can tell, the JVM GC is (not surprisingly) significantly more mature. The JVM has a concurrent mark-sweep algorithm that works similarly to what's described in this document, but more importantly IMO the JVM's GC is generational, and it appears Go's GC is not. In the JVM, the CMS only occurs on the oldest generation which contains objects that were in use for a while, whereas objects that are created and discarded quickly are cleaned up in younger generations with a copying collector, which avoids memory compaction by switching back and forth between 2 equally sized memory blocks. This means much of the time the JVM can avoid doing a full CMS and keep the time spent in GC only a few ms per second. I guess it depends on what your use case is. If you're writing low-latency server applications that don't have loads of long-lived internal state and you have memory to spare, the JVM's CMS GC is going to be way more efficient than Go's. But if you're constrained for memory then avoiding copying collectors and generational heaps is your best bet, but you'll pay for it in GC time. Of course the JVM has other GC algorithms like G1, but I don't have much experience with those.

schmichael 12y ago
> the JVM's GC is generational, and it appears Go's GC is not. Correct, that's slated for the 1.6 timeframe: > While other goals may intervene, 1.6 will most likely be used to improve throughput by adding bump pointer allocation as well as a generational copy collector for nursery (new) spaces. The mature (old) space will be managed using our concurrent GC. Source: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/preview?sle=true https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...
tmd83 12y ago
But if I'm reading it correctly GO GC will actually rely on a using a lot of memory to ensure it can hit the pause time goal. As far as I understand copying/generational collector by themselves don't add a lot of memory overhead. They simply add more complexity. You tend to require a lot more memory to ensure most your allocation & allocation happens in nursery (which can be scary fast and low overhead) and to allow the old generation GC to pace itself. I wonder how much of the 20% expected GC overhead comes from the fact that they can't do the nursery GC optimisation and whats the expected overhead when it goes generational in 1.6 One thing I absolutely hate with CMS is the fallback single thread collector for Old Gen that makes for a scary possibility. Don't think GO will have one of those which is nice to see (not for me though :().
mike_hearn 12y ago
G1 is the most advanced and is where the main development seems to be happening (ignoring Shenandaoh which is a Red Hat project to create an Azul style virtually-pauseless megascale GC). For example the G1 garbage collector can deduplicate strings in the heap. This can be a big win for servers and IDEs. In the latest update I read that G1 is also able to adapt itself to memory pressure in the entire operating system. If you start an app next to the JVM and the OS available memory drops, it'll start to use more CPU time for collection and shrink the heap so it can hand RAM back to the OS and reduce pressure again. G1 can do lots of other nifty things, but it uses more RAM than ParCMS so it's not the default at the moment. You have to opt into it. I think they want to make it the default one day.

schmichael 12y ago

> the JVM's GC is generational, and it appears Go's GC is not. Correct, that's slated for the 1.6 timeframe: > While other goals may intervene, 1.6 will most likely be used to improve throughput by adding bump pointer allocation as well as a generational copy collector for nursery (new) spaces. The mature (old) space will be managed using our concurrent GC. Source: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/preview?sle=true https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...

tmd83 12y ago

But if I'm reading it correctly GO GC will actually rely on a using a lot of memory to ensure it can hit the pause time goal. As far as I understand copying/generational collector by themselves don't add a lot of memory overhead. They simply add more complexity. You tend to require a lot more memory to ensure most your allocation & allocation happens in nursery (which can be scary fast and low overhead) and to allow the old generation GC to pace itself. I wonder how much of the 20% expected GC overhead comes from the fact that they can't do the nursery GC optimisation and whats the expected overhead when it goes generational in 1.6 One thing I absolutely hate with CMS is the fallback single thread collector for Old Gen that makes for a scary possibility. Don't think GO will have one of those which is nice to see (not for me though :().

mike_hearn 12y ago

G1 is the most advanced and is where the main development seems to be happening (ignoring Shenandaoh which is a Red Hat project to create an Azul style virtually-pauseless megascale GC). For example the G1 garbage collector can deduplicate strings in the heap. This can be a big win for servers and IDEs. In the latest update I read that G1 is also able to adapt itself to memory pressure in the entire operating system. If you start an app next to the JVM and the OS available memory drops, it'll start to use more CPU time for collection and shrink the heap so it can hand RAM back to the OS and reduce pressure again. G1 can do lots of other nifty things, but it uses more RAM than ParCMS so it's not the default at the moment. You have to opt into it. I think they want to make it the default one day.