Celebrity Compilers - Introduction to Compiler Construction in a Java World - page 279

increase the total size of the produced native machine code. That is why it is important
to apply this optimization selectively rather than blindly inlining every method call. The
HotSpot compiler applies method inlining in the detected program hot spots. HotSpot has
the freedom of inlining any method because it can always undo an inlining if the method's
inheritance structure changes during run time.
Undoing the inlining optimizations is called dynamic de-optimization. Suppose the com-
piler comes across to a virtual function call as
MyProgram.foo();
There are two possibilities here: the compiler can run the foo() function implemented
in MyProgram , or a child class's implementation of foo() . If MyProgram is defined as a
final class, or foo() in MyProgram is defined as a final method, the compiler knows that
MyProgram 's foo() should be executed. What if that is not the case? Well, then the compiler
has to make a guess, and pick whichever seems right to it at the moment. If it is lucky, there
is no need to go back; but that decision may turn out to be wrong or invalidated by a class
loaded dynamically that extends MyProgram during run time [Goetz, 2004]. Every time a
class is dynamically loaded, the HotSpot VM checks whether the interclass dependencies of
inlined methods have been altered. If there are any altered dependencies, the HotSpot VM
can dynamically de-optimize the affected inlined code, switch to interpretation mode and
maybe re-optimize later during run time as a result of new class dependencies. Dynamic
de-optimization allows HotSpot VM to perform inlining aggressively with the confidence
that possible wrong decisions can always be backed out.
If we look at the evolution of Oracle's JVM since the beginning, we see that it has
matured in stages. Early VMs always interpreted byte code, which could result in 10 to 20
times slower performance compared to C. Then, a JIT compiler was introduced for the first
time with JDK 1.2 as an add-on, which was originally developed by Animorphic Systems.
With JDK 1.3, HotSpot became the default compiler. Compared to the initial release, JDK
1.3 showed a 40% improvement in start-up time and a 25% smaller RAM footprint [Shudo,
2004]. Later releases further improved HotSpot even more [Kotzmann et al., 2008]. Thus, the
performance of a Java program written in Java code today approaches that of an equivalent
C program.
As an example of improvements made to HotSpot, consider the history of the JVM's
handling of the transfer of control between byte code and native code. In HotSpot's ini-
tial version, two counters were associated with each method: a method-entry counter and
a backward-branch counter. The method entry counter was incremented every time the
method was called while the backward-branch counter was incremented every time a back-
ward branch was taken (for example, imagine a for-loop; the closing brace of the for-loop's
body would correspond to a backward branch); and these counters were combined into a
single counter value with some additional heuristics for the method. Once the combined
counters hit a threshold (10,000 in HotSpot version 1.0) during interpretation, the method
would be considered \hot" and it then would be compiled [Paleczny et al., 2001]. How-
ever, the HotSpot compiler could only execute the compiled code for this method when the
method is called the next time.
In other words, if the HotSpot compiler detected a big, computationally intensive method
as a hot spot and compiled it into native code, say, because of a loop at the beginning of the
method, it would not be able to use the compiled version of the method until the next time
it was invoked. It was possible that heavy-weight methods were compiled during run-time
but the compiled native code would never be used [Goetz, 2004]. Programmers used to
\warm up" their programs for HotSpot by adding redundant and very long running loops
in order to provoke the HotSpot to produce native code at specific points in their program
and obtain better performance at the end.