Hacker News Reader

Comment by DougBTX | Hacker News Reader

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

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.

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-lang...

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.

Is that a good or bad thing? What’s the trade-off being made here?

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

That article is beyond out of date when it comes to Java GC.

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.

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)

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.

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.

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)

Shenandoah is also not generational, at least the implementation I looked at a year ago wasn't.

It's region-based, the regions serve a similar purpose to generations but in a more granular fashion.

The problem is that there is not benchmark for GC, but from my experience the Go GC is very good, aka sub 1ms.

Is this the case very large go heaps? ZGC claims sub ms pause for TB heap size.

Reply on news.ycombinator.com