JVM JIT optimization techniques
<i>for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM.</i><p>Funny statement, at least for Java. I don&#x27;t know anyone who would say the majority of Java applications <i>aren&#x27;t</i> huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. That&#x27;s mainly perception from when I briefly worked with Enterprise Java many years ago --- no one wrote &quot;simple&quot; or &quot;elegant&quot; Java applications, and stuffing as many design patterns and abstractions in as you could was considered &quot;best practice&quot;.<p>There are certainly examples of simple and small Java applications (see <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Java_4K_Game_Programming_Contest" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Java_4K_Game_Programming_Conte...</a> ), and I&#x27;ve written a few, but the overwhelming culture seems to be that of anti-optimisation and bureaucratic excess. In some sense, it&#x27;s almost like working <i>against</i> or &quot;challenging&quot; the JVM&#x27;s optimiser is the norm.<p>In my experience, a &quot;simple, elegant&quot; design --- which does <i>not</i> necessarily mean &quot;highly abstract&quot; --- tends to be very close to optimal anyway, with the compiler&#x27;s optimiser doing the remaining work. That makes me wonder whether claiming a language&#x2F;runtime&#x2F;compiler has powerful optimisation abilities is actually a reflection of how much the typical source code in the language has to be &quot;cleaned up&quot; by the optimiser in order to be decently efficient.<p>Also, does anyone else notice the &quot;Machine code&quot; given for the JIT example is <i>completely unrelated</i> to either the Java or bytecode? It&#x27;s 16-bit realmode --- I recognise the access to the 40h segment, it seems to be timing-related, and a bit of Googling finds that it&#x27;s actually part of an old TSR clock utility (with unknown source):<p><a href="http:&#x2F;&#x2F;assembly.happycodings.com&#x2F;code24.html" rel="nofollow">http:&#x2F;&#x2F;assembly.happycodings.com&#x2F;code24.html</a>