Maybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.
OK but again, that is a statement totally contrary to the article. The article is claiming two things: that it is easier in Go to avoid the heap while Java is utterly dependent on allocating everything on the heap - which is not consistent with the experience of actual Java and Go programmers - and that Java has a "preference for high throughput and high latency" which it doesn't.
FWIW, I used to write some high-performance JavaScript. One of the tricks of the trade was to allocate early and make sure you avoid allocating once the loading phase has started, hence avoiding triggering the garbage-collector (in most runtimes/languages, gc phases are typically triggered by the allocator). This involved writing very non-idiomatic code, to a large extent reimplementing a form of high-level custom allocator on top of the existing allocator/gc, but it worked.
I'd be very surprised if the same wasn't possible in Java.
I don't know if this is how gRPC is written but it could explain an apparent contradiction.
