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