Why Go can lower GC pauses to sub 1ms and JVM has

问题:

So there's that: https://groups.google.com/forum/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8:

Today I submitted changes to the garbage collector that make typical worst-case stop-the-world times less than 100 microseconds. This should particularly improve pauses for applications with many active goroutines, which could previously inflate pause times significantly.

High GC pauses are one if the things JVM users struggle with for a long time.

What are the (architectural?) constraints which prevent JVM from lowering GC pauses to Go levels, but are not affecting Go?

回答1:

What are the (architectural?) constraints which prevent JVM from lowering GC pauses to golang levels

There aren't.

High GC pauses are one if the things JVM users struggle with for a long time.

A little googling shows that similar solutions are available for java too

• Azul offers a pauseless collector that scales even to 100GB+
• Redhat is contributing shenandoah to openjdk and oracle zgc.
• IBM offers metronome, also aiming for microsecond pause times
• various other realtime JVMs

The other collectors in openjdk are, unlike Go's, compacting generational collectors. That is to avoid fragmentation problems and to provide higher throughput on server-class machines with large heaps by enabling bump pointer allocation and reducing the CPU time spent in GC. And at least under good conditions CMS can achieve single-digit millisecond pauses, despite being paired with a moving young-generation collector.

Go's collector is non-generational, non-compacting and requires write barriers (see this other SO question), which results in lower throughput/more CPU overhead for collections, higher memory footprint (fragmentation) and less cache-efficient placement of objects on the heap (non-compact memory layout).

回答2:

According to this presentation, Getting to Go: The Journey of Go's Garbage Collector, the Go collectors only utilize half of the heap for live data:

Heap 2X live heap

My impression is that Java GCs generally aim for higher heap utilization, so they make a very different trade-off here.