Also relevant is this series: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 "On mo

Also relevant is this series: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 "On modern JDK versions, the G1 is one monster of a collector. It handles heaps of dozens of GB with ease (we tried 60 GB), keeping maximum GC pauses within 200 ms." (note: 200msec is its default goal, not the limit of what it can do) Java has a reputation for needing complex GC tuning. Over time the need for this has fallen away as the GC technology has improved. https://jet-start.sh/blog/2021/03/17/billion-events-per-second https://jet-start.sh/blog/2021/03/17/billion-events-per-seco... "In our previous experience, we found you don't need any low-level GC tuning parameters to get great latency results on the JVM, but you do have to use a recent JDK. We let the JVM use its default G1 collector and configured it with our desired GC pause target." "the maximum throughput at which a single Hazelcast Jet node maintains 99.99% latency within 10 ms now lies at 20 million items per second, a 250% boost!" The JET guys show that a modern JVM (newer than Java 11) can achieve stunning throughputs with extremely low pause times. At 60fps each frame has 16 milliseconds to run. Obviously JET is a server and not a client-side app, but it helps put in perspective how impressive it is that your server could easily be running at "60fps" whilst processing 20 million items a second!