Why it is impossible to compile byte-code once on the final machine

So, why not once, when the program is “installed” (that is, the first hit) on a computer using jvm, compile the bytecode into machine code and then no longer use jvm?

Because then it will be impossible to use speculation, due to which JIT-compiled code can quite easily overtake AOT-compiled code. For example, we may have a method with the following signature:

void push(Consumer<Integer> consumer) 

In this case, the AOT will have nothing left except to use the Consumer interface and calculate the actually called method in runtime. However, if the JIT sees at the time of compilation that the method was invoked five thousand times with the same implementation of Consumer, it can discard everything that is superfluous, call directly a previously known method and put this so-called before. trap in case another implementation falls into the method and needs to be recompiled.

Also, JIT allows efficient inlining of code, which also occurs based on counting the number of calls and the size of the method. AOT cannot know which area will be hot without the help of a programmer (which, in turn, may be wrong), and JIT completely.

After all, there is the JIT that does the same thing, but during the execution of the program and only in chunks.

JIT does not do this in chunks, all code will be compiled into machine sooner or later, just until the compiler has worked, the interpreter works. Thanks to this, we can, for example, get an assembler listing.

A small not very professional explanation of the work of performers of the language.

Exist:

1. Compilers
2. Interpreters .
3. And compiler interpreters, or interpreters of compiling type .

Drop the first two and discuss the third.

The compiler of the interpreting type is essentially a two-in-one compiler and interpreter, such a performer is a JVM , after writing the program text, the JVM primarily uses a compiler that compiles your text into byte-code, while this stage has a number of optimizations empty loops, do not go through bytecode, it also happens that the compiler translates text into pure machine code, thanks to which such a crazy speed is achieved. But the next step will be the execution of this byte-code, and this is what the JIT interpreter, which interprets the machine and byte codes, is already engaged in, bringing us the result.

Accordingly, now you yourself have to understand why it is impossible to achieve a one-time execution - the program is in half, it is executed dynamically, that is, if byte code we can, in principle, be compiled once, but we need to interpret the byte code uniquely each time. This technology is called JIT interpreters .

And all that I have described here is without taking into account many other points, optimizations, hacks and technologies ... But as far as I know, from any Java application, for example, you can get a final executable file, it’s another question whether it’s convenient to achieve executable file and why do you need then the language on the JVM ? After all, the advantages of such languages ​​are objectively visible on servers, for example.

For classes of the standard library, this is already done starting with Java 9. It is believed that after a comprehensive run-in, the AOT compiler will become available for custom classes.

why it is impossible to once, with the "installation" of the program (that is, the first hit) on the computer using jvm, compile the byte code into machine code and then no longer use jvm?

The answer is very simple, jvm is a program that is already compiled into machine code. jvm cannot compile the code of your program into machine code when the program is “installed” because it is not a compiler.

The JDK includes a Java language compiler that compiles to bytecode. Bytecode is not machine code, so it can be executed only on jvm.

Although, in nature, Java compilers such as gcj were known, but for some reason they are not very popular.

Here is another implementation of the AOT, the so-called GraalVM . It is the substitution of another JVM virtual machine.

AOT Compilation:

The resulting program does not start on the Java HotSpot virtual machine, but uses the necessary components, such as memory management, scheduling flows from another implementation of the virtual machine called “Substrate Virtual Machine”. VM substrate is written in Java and compiled into its own executable file.