It's not just a handful of optimisations. The entire JVM is performance focused in a way the CLR just isn't. Microsoft historically put their resources into the

It's not just a handful of optimisations. The entire JVM is performance focused in a way the CLR just isn't. Microsoft historically put their resources into the C# language and the IDE. Sun/Oracle put their efforts into the runtime. For instance, the CLR doesn't do any profile guided or speculative optimisations at all. That's a 20% win for most Java apps and even more still for languages with higher levels of abstraction like Scala. So right there from the start .NET is 20% behind. The CLR doesn't have an interpreter, so, it spends a lot of time JIT compiling code that isn't particularly important. That takes CPU time away from your app, not sure how much of an effect that is but I can imagine it's at least another 10% down. C# asks devs to control de-virtualisation by hand to try and compensate, but the JVM can do a better job automatically. CLR is only now starting to look at tiered compilation and even then only a very basic form compared to Java which has had it since Java 8. But not only is the base infrastructure and approach far more advanced, the JVM's JIT compilers are way ahead of even the new RyuJIT. Not just fancy optimisations like devirt and escape analysis/scalar replacement, but even basic things like profile-guided basic block ordering. JVM can do auto-vectorisation of loops, lock optimisations, it can even replace speculatively profile and replace synchronised blocks with hardware (TSX) transactional memory. The CLR is multiple generations behind where HotSpot is. And the JVM team is extending its lead even further with projects like Graal.