Those are P99 latencies. Not sure how they measure, but my assumption is that, if you probe the JVM at a random point in time, ZGC (P99 = 0.1) will be unresponsive for 100us 1% of the time.
That’s… not incompatible with being useable in a low latency service, but 100us is 2.5 x longer than a sync disk write these days, and they don’t report max latency.
My take on the article is that GC has gotten quantifiably better since Java 8, but not qualitatively better:
The types of projects that had to abandon Java due to GC (and JIT) latency 10 (or 20) years ago still shouldn’t consider using Java.
I’m by no means an expert but even the OS’s scheduler can cause pauses on the range of 1ms — so the applications that can’t use Java, cannot really use ordinary OSs to begin with, can they?
Like, yeah, I would probably not write something like pipewire (linux’s new audio processing project) in Java, but other than that and like some really low latency trading niche (where FPGAs are dominant now as even general CPUs are slow), where would it preclude the usage of Java?
That’s… not incompatible with being useable in a low latency service, but 100us is 2.5 x longer than a sync disk write these days, and they don’t report max latency.
My take on the article is that GC has gotten quantifiably better since Java 8, but not qualitatively better:
The types of projects that had to abandon Java due to GC (and JIT) latency 10 (or 20) years ago still shouldn’t consider using Java.