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

Question

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

Today I submitted changes to the garbage collector that m

Answer 1

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

Principal I would say is that java is reference-oriented language, while Go is value-oriented language.

There are many aspects of it, Object metadata, Concurrency Handling... Naturally Java doesn't allow to put primitives in collections which give a lot of overhead in a sense of amount of Objects, in Golang you have Array, Slice and Map which support primitive types...

Here is a good article about Golang GC development and evolution.

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

Answer 3

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