5 ms·

Could someone provide a simple comparison with how other language runtimes (e.g. Java) implement GC?

wheaties 12y ago
The JVM has several different types of GC algorithms, many of which are tunable. (A better place to look to understand GC might actually be LuaJIT or Erlang. I say "might" because while I've been told that both have simple to understand implementations, I have not bothered myself to actually look at them.)
- rudolf0 12y ago
  Isn't LuaJIT's GC not that robust? I believe Mike Pall has lamented it as being the worst part of the compiler. I think he's wanted to rewrite it from scratch for a while, but doesn't yet have the time or resources.
  - nickik 12y ago
    He is working on it: http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
    - rudolf0 12y ago
      Mike last updated that page in 2012, and I'm not sure if he's publicly committed any code for it. I seem to recall him requesting a sponsorship for it.
- felixgallo 12y ago
  Erlang is mostly an immutable functional language without pointers, so for most scenarios not involving large binaries, its GC is completely trivial. For large binaries, a relatively primitive reference counting system is used. If I were to study GC from scratch, I'd start with http://www.hboehm.info/gc/ http://www.hboehm.info/gc/.
NullXorVoid 12y ago
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 :().

The JVM has several different types of GC algorithms, many of which are tunable. (A better place to look to understand GC might actually be LuaJIT or Erlang. I say "might" because while I've been told that both have simple to understand implementations, I have not bothered myself to actually look at them.)

rudolf0 12y ago
Isn't LuaJIT's GC not that robust? I believe Mike Pall has lamented it as being the worst part of the compiler. I think he's wanted to rewrite it from scratch for a while, but doesn't yet have the time or resources.
- nickik 12y ago
  He is working on it: http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
  - rudolf0 12y ago
    Mike last updated that page in 2012, and I'm not sure if he's publicly committed any code for it. I seem to recall him requesting a sponsorship for it.
felixgallo 12y ago
Erlang is mostly an immutable functional language without pointers, so for most scenarios not involving large binaries, its GC is completely trivial. For large binaries, a relatively primitive reference counting system is used. If I were to study GC from scratch, I'd start with http://www.hboehm.info/gc/ http://www.hboehm.info/gc/.

NullXorVoid 12y ago

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 :().