Manual memory management isn't magic and speeding up atomic ops doesn't fundamentally change anything. People have to spend time tuning memory management in C++

Manual memory management isn't magic and speeding up atomic ops doesn't fundamentally change anything. People have to spend time tuning memory management in C++ too, that's why the STL has so many ways to customise allocators and why so many production C/C++ codebases roll custom management schemes instead of using malloc/free. They're just expensive and slow so manual arena destruction etc is often worth it. The JVM already makes it extremely cheap to create and destroy objects: creation is always ~free (just a pointer increment), and then destruction is copying, so very sensitive to memory bandwidth but done in parallel. If most of your objects are dying young then deallocation is "free" (amortized over the cost of the remaining live objects). Given the reported bandwidth claims for the M1 if they ever make a server version of this puppy I'd expect to see way higher GC throughput on it too (maybe such a thing can be seen even on the 16GB laptop version). The problem with Java on the desktop is twofold: 1. Versions that are mostly used don't give memory back to the OS even if it's been freed by the collector. That doesn't start happening by default until like Java 14 or 15 or so, I think. So your memory usage always looks horribly inflated. 2. If you start swapping it's death because the GC needs to crawl all over the heap. There are comments here saying the M1 systems rely more heavily on swap than a conventional system would. In that case ARC is probably going to help. At least unless you use a modern pauseless GC where relocation is also done in parallel. Then pausing background threads whilst they swap things in doesn't really matter, as long as the app's current working set isn't swapped out to compensate.