Java bytecode

A common early assumption about Java goes like this: if a program is written as Java bytecode and an interpreter executes that bytecode, the program can never be as fast as a program that has already been compiled into the computer's native machine language. The assumption points at a real performance concern. Bytecode is not the machine's own language, and an interpreter has to work through it step by step. But the assumption leaves out an important part of how Java execution can work, and this article follows one program as it runs to show what that missing part is.

Imagine a Java program that has been turned into bytecode. As it runs, the bytecode is carried out by an interpreter, which executes the bytecode directly. Just-in-time compilation adds a further step inside this process: parts of the program can be translated into native machine language while the program is running. Those translated parts can then run from native machine language instead of being interpreted again. The diagram below shows where that translation step sits in the sequence from bytecode to running code.

Notice that the translation is not a separate build step that happens before the program starts. The source describes it as happening while the program is running. Interpretation and translation are both part of the same run, which is why the rest of this article compares them directly.

The key contrast is what happens to each bytecode instruction. With direct interpretation, the interpreter handles bytecode instructions one by one as the program runs. With just-in-time compilation, a section of the program can be translated into native machine language, so that later runs of that section use the translated form. The source notes that interpreted bytecode can run slower than native machine language, but translated parts can execute much more quickly than they could through interpretation. The comparison below lays out both execution paths side by side.

The benefit of just-in-time compilation comes from repetition. A given part of a program is often executed many times as the program runs. If that part is translated into native machine language during execution, later execution of the translated part can be faster than repeatedly interpreting it. The translation itself takes place while the program runs, but the translated result can improve overall execution time when the relevant part is used repeatedly. The source states that the greatest benefit occurs when a program part is executed many times.

The diagram shows the trade-off. Translation has a cost that is paid once. The reuse afterward can be repeated many times, so the saving can add up. This is why a section that runs only once gains little from translation, while a section that runs many times is a strong candidate for it.

The early assumption is a useful starting point, but it is stated too strongly. The more precise version is that interpreted Java bytecode can run slower than native machine language, while just-in-time compilation can translate parts of the bytecode into native machine language during execution. Those parts can then run much faster than they would through interpretation.