Re: Crash Course In Modern Hardware
Lew wrote:
Hotspot runs bytecode altogether, at first (JNI excluded from
consideration here). Based on actual runtime heuristics, it might
convert some parts to native code and run the compiled version. As
execution progresses, Hotspot may revert compiled parts back to
interpreted bytecode, depending on runtime situations.
Arne Vajh??j wrote:
Nothing in any spec prevents it from doing so, but I am skeptical
about whether any implementations would do so.
Well, either Sun is a bunch of big, fat liars, or you can set your skepticism
aside:
<http://java.sun.com/products/hotspot/whitepaper.html#dynamic>
"Both the Java HotSpot Client and Server compilers fully support dynamic
deoptimization."
If it actually has spend time JIT compiling why should it go
back to interpreting?
Some of the reasoning is explained in
<http://java.sun.com/products/hotspot/whitepaper.html#3>
There's more detail in
<http://java.sun.com/products/hotspot/docs/general/hs2.html>
"The Java HotSpot Server VM can revert to using the interpreter whenever
compiler deoptimizations are called for because of dynamic class loading. When
a class is loaded dynamically, HotSpot checks to ensure that the inter-class
dependecies [sic] of inlined methods have not been altered. If any
dependencies are affected by dynamically loaded class [sic], HotSpot can back
out affected inlined code, revert to interpreting for a while, and re-optimize
later based on the new class dependencies."
One of my favorite experts, Brian Goetz, wrote about this back in 2004:
<http://www.ibm.com/developerworks/library/j-jtp12214/>
"[T]he JVM continues profiling, and may recompile the code again later with a
higher level of optimization if it decides the code path is particularly hot
or future profiling data suggests opportunities for additional optimization.
The JVM may recompile the same bytecodes many times in a single application
execution."
and later, discussing inlining,
"... the JVM can figure this out, and will invalidate the generated code that
is based on the now-invalid assumption and revert to interpretation (or
recompile the invalidated code path)."
Despite your skepticism, not only has one (in fact, the) implementation done
dynamic reversion to interpreted bytecode, but it's been doing so for quite
some years.
--
Lew