Hacker News Reader

Comment by Alifatisk | Hacker News Reader

What would having a parallel GC mean in the practical sense?

That there is no pauses happening during the runtime?

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.

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.

No, it simply means that it can better utilize multiple cores to do the GC work faster, so pauses will be proportionally shorter. With the current SBCL collector (or the old one, since this one is already released), even if you ran on a 16-core system, the GC would still only use a single core to reclaim memory (in practice, to move some of/all your live objects to a different address, as it was a copying collector).

Reply on news.ycombinator.com