I guess what you mean is the no-op garbage collector which is available in Java 11 http://openjdk.java.net/jeps/318 http://openjdk.java.net/jeps/318 Even this

I guess what you mean is the no-op garbage collector which is available in Java 11 http://openjdk.java.net/jeps/318 http://openjdk.java.net/jeps/318 Even this isn't fail proof right ? Last-drop latency improvements. For ultra-latency-sensitive applications, where developers are conscious about memory allocations and know the application memory footprint exactly, or even have (almost) completely garbage-free applications, accepting the GC cycle might be a design issue. There are also cases when restarting the JVM -- letting load balancers figure out failover -- is sometimes a better recovery strategy than accepting a GC cycle. In those applications, long GC cycle may be considered the wrong thing to do, because that prolongs the detection of the failure, and ultimately delays recovery. So essentially you need to know the memory footprint of your applications. To err on the side of caution just get as much memory that is available in the market. At this point like another reply mentions here aren't you just better off writing C++ code ?