Earlier quoted context omitted.
Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find. I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases: "We now have an objective of 500 microseconds stop the world pause per GC cycle." - 2018 Go team https://blog.golang.org/ismmkeynote My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The b…
I was talking about technology state of the art, not out-of-the-box experience. OpenJDK's default collector - parallel or G1GC, depending on version - is not the best available among JVMs and if your goal is pause times then yes, it will be worse than Go's. But if you switch to say C4 or ZGC you'll get comparable pause times and compacting on top and being able to scale to terabyte heaps. 10 years ago we had Metronom…
> 25% GC overhead in older versions of Go, that's utterly terrible.
25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense.
The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png
2014 Go: 25% of CPU used by GC
2018 Go: 25% of CPU used during 2x STW GC of So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.