Hacker News Reader

There are still pauses, but the pauses are faster by using multiple cores to collect, which is nice for both throughput- and latency-sensitive apps. No-pause ("on-the-fly") collectors exist, but sufficiently-short pause ("concurrent") collectors still do wonders with sub-millisecond latency.

View on HN

The new GC is not concurrent, it is still a stop-the-world collector. The improvement is that it can do the collection and compaction work in parallel on a multi-core machine.

As such, it will greatly increase throughput if given multiple cores, and will lead to lower pause times based on this improvement in throughput.

> As such, it will greatly increase throughput if given multiple cores, and will lead to lower pause times based on this improvement in throughput.

If given many cores or perhaps in a later revision with improved efficiency. Today throughput on a four core CPU seems to be lower.

The mark-region GC has worse throughput with really large heaps compared to the live set (as the cost model doesn't work out), and always had* worse latency on Kandria. But generally throughput with more than two cores tends to be better.

* I expect latency to be better with compacting, but I haven't benchmarked, so I haven't a clue.

Reply on news.ycombinator.com