[defer]

JVM does garbage collection, this can stop all threads at safepoints while GC occurs.

Those stops can be enough to ruin your low latency requirements in the high percentiles. A common strategy is to divide workloads between jvms so that you meet the requirement.

[joas_coder]

CoralRing and CoralQueue (available on GitHub) are completely garbage-free. You can send billions of messages without ever creating garbage for the GC, so no GC overhead. This is paramount for real-time ultra-low-latency systems developed in Java. You can read more about it here => https://www.coralblocks.com/index.php/java-development-witho...

[nwellinghoff]

Interesting. But how do you ensure a worker that picks up a task does not pause on gc as well?

[joas_coder]

CoralRing does not produce garbage, but it cannot control what other parts of your application choose to do. It will hand to your application a message without producing any garbage, now if you go ahead and produce garbage yourself then there is nothing CoralRing can do about that. Ultra-low-latency applications in Java are designed so that nothing in the critical path produces garbage.

[dikei]

Maybe they run a small heap with a zero-pause JVM like Zing, as pause-less GC generally has lower throughput than normal GC.

[pebal]

Java doesn't have real pause-less GC.

[dikei]

Well, "pause too short to matter" just doesn't have the same ring to it.

[pebal]

One millisecond is not a short pause.

[touisteur]

Modern low-latency GCs never reach 1ms on all the workloads I've put them through. Mind you I don't GC terabytes of RAM so who knows what happens there.