|
|
От: |
Cyberax
|
|
| Дата: | 04.04.06 08:16 | ||
| Оценка: | 13 (1) | ||
Its name derives from the fact that as it runs Java byte-code, it
continually analyzes the program's performance for "hot spots"
which are frequently or repeatedly executed. These are then targeted for
optimization, leading to high performance execution with a minimum of
overhead for less performance-critical code.
The Hotspot VM begins by interpreting all code, but it monitors
the execution of that code. As mentioned earlier, most programs spend 80
to 90 percent of their time executing 10 to 20 percent of the code. By
monitoring the program execution, the Hotspot VM can figure out which
methods represent the program's "hot spot" -- the 10 to 20 percent of
the code that is executed 80 to 90 percent of the time.
When the Hotspot VM decides that a particular method is in the hot spot,
it fires off a background thread that compiles those bytecodes to
native and heavily optimizes the native code. Meanwhile, the program
can still execute that method by interpreting its bytecodes. Because the
program isn't held up and because the Hotspot VM is only compiling and
optimizing the "hot spot" (perhaps 10 to 20 percent of the code), the
Hotspot VM has more time than a traditional JIT to perform optimizations.
...
The Hotspot VM keeps the old bytecodes around in case a method moves
out of the hot spot. (The hot spot may move somewhat as the program
executes.) If a method moves out of the hot spot, the VM can discard
the compiled code and revert back to interpreting that method's
bytecodes.
One advantage Hotspot's adaptive optimization approach has over static
compilation is that, because it is happening at runtime, it can use
information not available to a static compiler. For example, even though
there may be 30 possible implementations that may get called for a
particular method invocation, at run-time perhaps only two of them are
ever called. The Hotspot approach enables only those two to be inlined,
thereby reducing the exploding size problem.
