They compile the bytecode just-in-time to native machine code, using many of the same techniques a conventional native code compiler.
From the Hotspot Wikipedia page:
"Both VMs compile only often-run methods, using a configurable invocation-count threshold to decide which methods to compile."[1]
Also see very old discussions at StackOverflow[2][3]. Then of course there are compilers (eg. gcj) which compile to native up-front.
[1] https://en.wikipedia.org/wiki/HotSpot#Features
[2] https://stackoverflow.com/questions/7100365/why-doesnt-javas...
[3] https://stackoverflow.com/questions/16568253/difference-betw...
This is by design, and if you need everything compiled right away you can set the compilation threshold to 1.
I don't see any value in compiling parts of code that only gets executed during bootstrap.
https://www.oracle.com/java/technologies/javase/vmoptions-js...
https://chriswhocodes.com/hotspot_options_jdk14.html
Not disagreeing with you there, since stopping to compile code/optimize at runtime contributes to sluggish interactive performance.
No JVM I am aware of stops to compile - the compiler runs on a background thread while the application continues to run as normal.
Who are you disagreeing with? I didn’t say that’s the only way they execute bytecode, did I?
The question was how it’s executed ‘after they warm up’.
> Then of course there are compilers (eg. gcj) which compile to native up-front.
But I was replying to someone who asked specifically about how ‘production JVMs’ do it, not how discontinued compilers do it.
Nope, my bad. Thanks for clarifying.
They compile the bytecode just-in-time to native machine code, using many of the same techniques a conventional native code compiler.