5 ms·

Also notably Go, though really all GC languages which care about performance, of which there are quite a few.

the8472 5y ago
Go isn't playing in the same league though since their GC is non-generational and non-compacting. A lot of the difficulties implementing concurrent GCs comes from moving things between generations and compacting.
- DougBTX 5y ago
  I had this benchmark[0] in mind while writing the comment, though perhaps Go does well there by avoiding GC rather than having fast GC as-such? That would explain why its performance is close to the non-GC languages. [0] https://awesomeopensource.com/project/ixy-languages/ixy-languages https://awesomeopensource.com/project/ixy-languages/ixy-lang...
  - throwaway894345 5y ago
    Without digging into that benchmark, Go leans on stack allocation a lot more than many GC languages, and that’s a big part of why Go is able to achieve otherwise impressive performance. The same mechanism (idiomatic value types) that allows Go to elide GC in many cases also permits better cache coherency—there are fewer pointers into random regions of the heap so cache lines need to be flushed less frequently.
- stingraycharles 5y ago
  Is that a good or bad thing? What’s the trade-off being made here?
  - 5e92cb50239222b 5y ago
    https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
    - vips7L 5y ago
      That article is beyond out of date when it comes to Java GC.
  - throwaway894345 5y ago
    Compacting 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 ago
      Though 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 ago
        I’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 ago
        As 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 ago
        Interesting. 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)
- isbvhodnvemrwvn 5y ago
  Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.
  - the8472 5y ago
    It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.
- Thaxll 5y ago
  The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.
  - SureshG 5y ago
    Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.

Go isn't playing in the same league though since their GC is non-generational and non-compacting. A lot of the difficulties implementing concurrent GCs comes from moving things between generations and compacting.

DougBTX 5y ago
I had this benchmark[0] in mind while writing the comment, though perhaps Go does well there by avoiding GC rather than having fast GC as-such? That would explain why its performance is close to the non-GC languages. [0] https://awesomeopensource.com/project/ixy-languages/ixy-languages https://awesomeopensource.com/project/ixy-languages/ixy-lang...
- throwaway894345 5y ago
  Without digging into that benchmark, Go leans on stack allocation a lot more than many GC languages, and that’s a big part of why Go is able to achieve otherwise impressive performance. The same mechanism (idiomatic value types) that allows Go to elide GC in many cases also permits better cache coherency—there are fewer pointers into random regions of the heap so cache lines need to be flushed less frequently.
stingraycharles 5y ago
Is that a good or bad thing? What’s the trade-off being made here?
- 5e92cb50239222b 5y ago
  https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
  - vips7L 5y ago
    That article is beyond out of date when it comes to Java GC.
- throwaway894345 5y ago
  Compacting 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 ago
    Though 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 ago
      I’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 ago
        As 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 ago
        Interesting. 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)
isbvhodnvemrwvn 5y ago
Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.
- the8472 5y ago
  It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.
Thaxll 5y ago
The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.
- SureshG 5y ago
  Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.