Hotspot

from Wikipedia, the free encyclopedia
Hotspot
Basic data

Maintainer Oracle
developer Oracle
Current  version 22
(December 12, 2011)
operating system cross-platform
programming language C / C ++
category Java Virtual Machine
License GNU General Public License
Website about Sun's OpenJDK HotSpot

HotSpot is a widely used Java Virtual Machine from Oracle (previously from Sun Microsystems ) for workstations and servers , published under the name Java HotSpot Performance Engine . It is based on techniques such as just-in-time compilation and adaptive optimization to improve the runtime behavior of software during execution.

History of origin

The origin of HotSpot goes back to a group of programmers who worked on the Self programming language at Sun Microsystems in the early 1990s . These programmers Lars Bak , Gilad Bracha , Steffen Grarup , David Griswold , Robert Griesemer and Urs Hölzle left Sun in 1994 and jointly founded a company called Longview Technologies , which also appeared under the name Animorphic Systems , in order to use Smalltalk (programming language) based as an option Developing the Strongtalk typed programming language . There Urs Hölzle succeeded in developing a type feedback compiler, and the Strongtalk VM also made great progress. Due to the rapid development of the new Java programming language released by Sun, it was decided to develop a fundamentally new Java virtual machine . During this time Srdjan Mitrovic was accepted, who took care of the integration of Java in the new VM. In 1997, Sun bought Longview Technologies and Lars Bak became Sun's lead engineer on Hotspot VM. At the time of the takeover, HotSpot was around twice as fast as the JVMs on the market at the time. For its part, Sun Microsystems was acquired by Oracle in 2010 .

overview

The Sun Java Server (also Opto or C2) compiler converts the Java bytecode of the Java Virtual Machine (JVM) into executable machine code of the corresponding target platform. It is a highly optimizing just-in-time compiler (JIT). In contrast to ahead-of-time compilers such as GCC, just-in-time compilers only generate the machine code when the program is running. In addition to the actual runtime of the program, the compilation process itself has an impact in the form of CPU cycles and longer runtime. However, since this (compilation) process is only used adaptively, i.e. with some methods (so-called hotspots), this effort is unique and especially for long-running server applications very short compared to the program execution time, this additional effort is quickly due to the higher quality of the generated machine code compensated. It is also compiled on a separate thread , which on SMP machines usually runs on a separate CPU.

At the beginning of the runtime of a Java program, the entire bytecode is only interpreted. This happens in an interpreter loop that processes bytecode by bytecode. The specialty of hotspot compilers is that they only translate frequently used code sections - so-called “hotspots” - into machine code . The hotspots are also discovered locally, i.e. within methods, but the smallest compilation unit is always the method. Since the translation only takes place with particularly frequently used or long-running methods and not with the entire code, the additional effort, especially for long-running applications, is negligible.

The advantage of this procedure lies in the possibility of performing closed-world optimizations as well as applying dynamic optimizations . This means that the JVM always knows the entire loaded bytecode and can use it to make optimization decisions that change the semantics of the code so that it only works correctly under the existing conditions of use. If code is loaded at runtime that changes these operating conditions, the (server) hotspot VM performs a de-optimization - and thus guarantees correct functioning by removing and re-optimizing the code that is too aggressively optimized for this use.

The compilation process of the Sun hotspot compiler consists of the following steps:

Hotspot detection, compile policy

The basic procedure, how and under which circumstances a method is compiled, is defined in the Sun JVM by so-called compile policies . In the case of the server compiler, these guidelines, modeled in a C ++ class hierarchy, are StackWalkCompPolicystored in the class . The compilation process can thus be reconfigured by changing or adapting the guidelines. In practice, however, this happens relatively rarely, apart from setting the flag -XX:+CompileTheWorldfor translating literally all methods. The name StackWalkCompPolicy goes back to the algorithm of checking the call stack of the methods to be examined upwards until the first method is discovered that will no longer lead to inlining.

In the server compiler, two threshold values ​​are used to identify the hotspots:

Frequency of calling a method
This threshold value is kept in the JVM-internal variable CompileThreshold and has different basic settings on the various platforms. On the Intel 386 architecture , there are 10,000 method calls for the server JVM and 1,500 for the client JVM.
Number of loops in a method
If loops in methods are executed too often, this also marks a method for compilation. The frequency of a loop run is in turn counted individually in so-called backedge counters for each loop.

There are already provisions in the server compiler to support so-called two-tier compilation in later versions. The aim is to first compile a method quickly and without massive optimization and later (or in parallel) to translate it in a highly optimized manner in a further run. This “two tier compilation” will lead to a merging of server and client compiler .

Compilation

After the policy control has marked individual methods for compilation, an CompileTaskobject is created for each of the methods and placed in the CompileQueue. That, as well as the other control of the entire translation process, is the responsibility of the CompileBroker. This generates the individual translation jobs ( CompileTask), puts them in the queue and finally wakes up with an notify()inactive compile thread. The number of compile threads is usually log (number of CPUs), but at least two. Various PerfCounterobjects are also kept in the CompileBroker , which can be used for subsequent performance monitoring or display.

Now the bytecode is converted in different phases. The most important steps are:

  • Parsing the byte code
  • Deleting unused nodes ( nodes )
  • Choosing the instructions.
  • Global Value Numbering (GVN)
  • Generate Control Flow Graph (CFG)
  • Allocation tab ( Chaitin Graph Coloring )
  • Peephole optimization

The internal representation (IR) of the program run is saved in SSA format.

optimization

Among other things, by storing the node graph in SSA format, it is possible to use a number of optimization methods. Here are the most important:

Inlining
Short methods (maximum 35 bytes ) are inserted into the body of the caller instead of being jumped to. Inlining is not profitable with longer methods.
Loop unrolling
Short loops are "unrolled", so to speak, that is, the individual loop passes are processed sequentially without jumping back. Similar to inlining, this increases the memory consumption, but with a few loops it is cheaper than constantly testing a jump condition.
Dead Code Elimination
Unused instructions are detected and discarded at the bytecode level. Although this optimization at the source code level by the Java Frontend Compiler (javac) is used far more, this step is also used at the bytecode level.
Peephole optimization
Optimization at assembly level. Here, a context ( peephole ) is generated using a few assembler instructions and, for example, redundant memory accesses are eliminated and register accesses are optimized.

Code generation, activation

AD files

The code generator (emitter) of the system generates machine code on the basis of prefabricated templates that save assembler code sections corresponding to the bytecode in so-called architecture description files (AD files). In these files the various CPUs are described abstractly with their assembler commands, addressing modes and especially the number and width of the registers. The AD files are translated into C ++ classes using a special preprocessor, which are incorporated into the VM build process.

CompileCache

The assembly language instructions created by the compiler are stored in the CompilerCachewith a reference to the original bytecode. This is necessary in order to be able to access the bytecode again during a later de-optimization. Deoptimisation may be necessary if, for example, dynamically loaded classes in which individual methods have been embedded ( inlining ) are replaced by new ones at runtime.

Stubs

The machine code generated by the compilation process cannot function without using the services of the VM. In one method, for example, a name lookup in the symbol table must be carried out again and again , a reference must be resolved or other JVM services must be used. That is why so-called stubs are repeatedly inserted into the machine code, through which the compiled code makes contact with the outside world.

Activate the compilation

Basically, the completed method can either be exchanged at runtime of the bytecode or used at the time of the next call. Interrupting a running method and replacing it with the compiled version is called on-stack replacement (OSR). In order to accomplish this highly dynamic operation, so-called savepoints are inserted in the bytecode. The virtual machine is in a defined, synchronized state at these savepoints . Now the bytecode is exchanged for the compilation and the exact corresponding CPU stack is generated synthetically.

literature

  • Michael Paleczny, Christopher Vick, Cliff Click: The Java HotSpot server compiler . In: Proceedings of the Java Virtual Machine Research and Technology Symposium on Java Virtual Machine Research and Technology Symposium - Volume 1 . USENIX Association, Monterey, California 2001 ( acm.org ).
  • Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman: Compiler. Principles, Techniques, and Tools. Addison-Wesley, Reading 1988, ISBN 0-201-10194-7 (the "Dragon Book").

swell

  1. ^ The Java HotSpot Performance Engine Architecture. Retrieved June 9, 2020 .
  2. ^ The History of the Strongtalk Project by Dave Griswold.
  3. ↑ Sun buys Java compiler technology based upon Self !!! Keith Hankin February 18, 1997
  4. ↑ Engineers to make significant contributions to Sun's Java Platform ( Memento of April 20, 1999 in the Internet Archive ), Mountain View February 18, 1997
  5. ↑ Google 'Crankshaft' inspired by Sun Java HotSpot - Bak to 'adaptive compilation' by Cade Metz, December 9, 2010
  6. ↑ Language Based Virtual Machines… or why speed matters ( Memento of the original from September 23, 2015 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. by Lars Bak  @1@ 2Template: Webachiv / IABot / www.aosd.net

Web links