<\/div>\n

This blog post is not about SubstrateVM nor GraalVM but focuses on the jaotc<\/span> <\/em>AOT compiler in HotSpot.<\/em><\/p>\n

Introduction<\/h2>\n
In this blog post, we are going to focus on the Ahead-Of-Time (AOT) Compilation that was introduced in Java 9 (https:\/\/openjdk.java.net\/jeps\/295<\/a>) with the addition of the jaotc<\/span> command-line utility. This AOT compiler is based on the work done in Graal JIT.<\/p>\n
We are going to explore some of the tradeoffs that the AOT compiler needs to take, and how the generated code fits in the Tiered Compilation (TC) pipeline. Then, we will go through a simple example, showing how to use the jaotc<\/span>\u00a0command-line utility. Finally, we are going to explore some alternatives to the AOT compiler like JIT at Startup, JIT caching, and Distributed JIT.<\/p>\n
AOT Compilation in HotSpot<\/h2>\n
An AOT compiler’s primary capability is to generate machine code for an application without having to run the application, allowing a future run of the application to pick the generated code. Similarly, to C1 and C2, jaotc<\/span>\u00a0compiles Java bytecode to native code.<\/p>\n
The primary motivator behind using AOT in Java is to bypass the interpreter. It is generally faster for the machine to execute machine code than it is to execute the code via the bytecode interpreter. In many cases, it is a definite advantage, especially for code that needs to be executed even just a few times.<\/p>\n
Tradeoffs of generated code<\/h3>\n
An AOT compiler cannot make the same class of assumptions as a JIT compiler. The AOT compiler doesn\u2019t have access to as much information as the JIT compiler does because the process generating and executing the application are not the same.<\/p>\n
For example, AOT compilers are required to generate Position Independent Code (PIC) to produce shared libraries. That is because there is no way to know ahead of execution where in memory the code is loaded, blocking any assumption the AOT compiler can make on the location (relative or absolute) of a symbol; this prevents the AOT compiler from referencing the address of any symbol directly. So, whenever a symbol (such as functions and constants) is accessed, it requires the AOT compiler to generate an indirection, with the resolution happening on first access to the symbol.<\/p>\n
On the other hand, a JIT compiler can take the address in memory of a symbol and embed it directly in the code. It works because the JIT compiler can assume the code to have a shorter lifetime than the symbol: the code generation happens after the symbol initialization (or at least the code generation initializes the symbol), and the shutdown of the process triggers the destruction of both the code and the symbol.<\/p>\n
Another example is final static<\/span> variables. A JIT compiler can make certain assumptions allowing it to generate code based on the value of the variable. But because an AOT compiler cannot know the value of the variable before<\/em> the initialization of the variable \u2013 which only happens at the execution of the code \u2013 it can\u2019t make the same assumptions. That can lead to missed optimizations opportunities like dead-code elimination or inlining.<\/p>\n
Finally, the OS and architecture on which you execute the code and on which you generate the code are required to be the same. For example, if you want to execute the code on Windows, you cannot generate the code on Linux or macOS but only on Windows. That is because the jaotc<\/span> does not support cross-compilation.<\/p>\n
Integration with the Tiered Compilation pipeline<\/h3>\n
Introduced in Java 7, Tiered Compilation (TC) goal is to have fast startup time and fast steady-state throughput. The implementation consists of a pipeline of multiple tiers of code generation. The three main components of this pipeline are the interpreter, the C1 compiler, and the C2 compiler. It replaced the -client<\/span> and -server<\/span> command-line parameters available in previous versions of Java.<\/p>\n
As the method goes through the different tiers, each tier gathers information about the method execution. This information is called Profiling Data (PD). The C2 compiler uses this PD to make certain assumptions such as what code paths are cold\/warm\/hot, and what types are used at any call sites. It can then generate code better suited for the specific context that it is currently executing in.<\/p>\n
The five tiers of code generation are:<\/p>\n
\n
none (0):<\/strong> Interpreter gathering full PD<\/li>\n
simple (1):<\/strong> C1 compiler with no profiling<\/li>\n
limited profile (2):<\/strong> C1 compiler with light profiling gathering some PD<\/li>\n
full profile (3):<\/strong> C1 compiler with full profiling gathering full PD<\/li>\n
full optimization (4):<\/strong> C2 compiler with no profiling<\/li>\n<\/ul>\n
With jaotc<\/span>, you have the option to generate code with or without support for TC. Enabling TC generates slightly slower code due to the profiling overhead. Disabling TC blocks the use of the TC pipeline leading to slower steady-state throughput.<\/p>\n
Figure 1 and Figure 2 show the flow in the TC pipeline if you use AOT or not.<\/p>\n
<\/p>\n