Editing Just-in-time compilation (section)

== Design ==

In a bytecode-compiled system, [[source code]] is translated to an [[intermediate representation]] known as [[bytecode]]. Bytecode is not the machine code for any particular computer, and may be [[software portability|portable]] among computer architectures. The bytecode may then be interpreted by, or run on a [[virtual machine]]. The JIT compiler reads the bytecodes in many sections (or in full, rarely) and compiles them dynamically into machine code so the program can run faster. This can be done per-file, per-function or even on any arbitrary code fragment; the code can be compiled when it is about to be executed (hence the name "just-in-time"), and then cached and reused later without needing to be recompiled.

By contrast, a traditional ''interpreted virtual machine'' will simply interpret the bytecode, generally with much lower performance. Some ''interpreter''s even interpret source code, without the step of first compiling to bytecode, with even worse performance. ''Statically-compiled code'' or ''native code'' is compiled prior to deployment. A ''dynamic compilation environment'' is one in which the compiler can be used during execution. A common goal of using JIT techniques is to reach or surpass the performance of [[static compilation]], while maintaining the advantages of bytecode interpretation: Much of the "heavy lifting" of parsing the original source code and performing basic optimization is often handled at compile time, prior to deployment: compilation from bytecode to machine code is much faster than compiling from source. The deployed bytecode is portable, unlike native code. Since the runtime has control over the compilation, like interpreted bytecode, it can run in a secure sandbox. Compilers from bytecode to machine code are easier to write, because the portable bytecode compiler has already done much of the work.

JIT code generally offers far better performance than interpreters. In addition, it can in some cases offer better performance than static compilation, as many optimizations are only feasible at run-time:<ref name="Croce" /><ref name="stackoverflow-1" />

# The compilation can be optimized to the targeted CPU and the operating system model where the application runs. For example, JIT can choose [[SSE2]] vector CPU instructions when it detects that the CPU supports them. To obtain this level of optimization specificity with a static compiler, one must either compile a binary for each intended platform/architecture, or else include multiple  versions of portions of the code within a single binary.
# The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. However, some static compilers can also take profile information as input.
# The system can do global code optimizations (e.g. [[inline expansion|inlining]] of library functions) without losing the advantages of dynamic linking and without the overheads inherent to static compilers and linkers. Specifically, when doing global inline substitutions, a static compilation process may need run-time checks and ensure that a virtual call would occur if the actual class of the object overrides the inlined method, and boundary condition checks on array accesses may need to be processed within loops. With just-in-time compilation in many cases this processing can be moved out of loops, often giving large increases of speed.
# Although this is possible with statically compiled garbage collected languages, a bytecode system can more easily rearrange executed code for better cache utilization.

Because a JIT must render and execute a native binary image at runtime, true machine-code JITs necessitate platforms that allow for data to be executed at runtime, making using such JITs on a [[Harvard architecture]]-based machine impossible; the same can be said for certain operating systems and virtual machines as well. However, a special type of "JIT" may potentially ''not'' target the physical machine's CPU architecture, but rather an optimized VM bytecode where limitations on raw machine code prevail, especially where that bytecode's VM eventually leverages a JIT to native code.<ref name="stackoverflow-2" />