Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Your CPU never runs Java source code, and in the usual software path it never runs JVM bytecode either. The Java compiler (javac) produces class files containing instructions for the Java Virtual Machine. A JVM implementation then executes them. In HotSpot, the JVM most developers use, that means interpreting at first, watching what runs often, and compiling the hot parts into native machine code for the host CPU. “Rewrites” is useful shorthand, but not literal: bytecode isn’t replaced, and not every method gets compiled.
The pipeline, step by step
For a typical HotSpot run, the path looks like this:
- Java source (
.java) is what you write. - The Java compiler turns it into class files holding JVM bytecode, a machine-independent instruction set.
- The JVM loads the classes and begins executing them.
- Interpretation and profiling: HotSpot’s interpreter launches the program and gathers data on which code is hot.
- Selective JIT compilation: performance-critical portions are compiled to native instructions for the host.
- The CPU executes native instructions. These are either the JVM’s own code (including the interpreter, itself native) or the code the JIT generated.
Every arrow here is qualified. The JVM specification defines behavior, not one mandatory internal strategy, so this is the documented HotSpot story rather than a guarantee for every JVM.
What Oracle says about bytecode
Oracle’s Java Language Environment documentation states: “The Java compiler doesn’t generate “machine code” in the sense of native hardware instructions–rather, it generates bytecodes: a high-level, machine-independent code for a hypothetical machine that is implemented by the Java interpreter and run-time system.” It continues: “Java bytecodes are designed to be easy to interpret on any machine, or to dynamically translate into native machine code if required by performance demands.” The page doesn’t name an individual author.
Note the phrase “if required by performance demands.” Translation to native code is presented as an option, not a mandatory step.
Java, bytecode and the JVM are different things
- Java is a programming language. Other languages can also target the JVM, and the class-file format is what the JVM consumes.
- Bytecode is the instruction format in class files.
- The JVM is a specified virtual machine. The specification describes the class-file format and the execution model; implementations may differ internally as long as they meet it.
- HotSpot is one implementation. Oracle describes it as a bytecode execution engine for a range of operating systems and architectures.
The specification mentions platform-specific code generation by a just-in-time (JIT) translator as one possible step once JVM code is loaded. It leaves the choice to the implementor.
Rank #2
Interpretation versus JIT compilation
| Aspect | Interpretation | JIT-compiled execution |
|---|---|---|
| Starting point | Begins executing without first compiling everything to native code | Selected code is translated to host-native instructions |
| Role in HotSpot | Launches the application and can collect profile information | Targets the hot, performance-critical portions identified at runtime |
| Typical fit | Code that runs rarely or only once | Code that runs often enough to repay the compilation cost |
Oracle’s HotSpot overview describes exactly this: an interpreter starts the application, analysis detects bottlenecks (“hot spots”), and the performance-critical portions are compiled. Seldom-used code need not be compiled at all. So the answer to “does the JVM compile every method?” is no.
Why compile at runtime instead of ahead of time?
Bytecode gives Java a portable target: the same class files can run wherever a suitable JVM exists. Compiling at runtime lets the VM use knowledge gathered on the actual machine and from the actual execution of the program when optimizing the code that matters. The trade-off is that compilation work happens while the program runs, which is why compiling only what is hot makes sense.
Tiered compilation
HotSpot doesn’t just flip from “interpreted” to “compiled.” Oracle’s Java SE 8 performance guide describes tiered compilation: a client compiler first produces compiled methods that also gather profiling information, and the server compiler can later apply deeper optimization using that data. The documented aims are better execution while profiling is under way and more time for the later, heavier optimization.
| Axis | Early compiled stage | Later optimizing stage |
|---|---|---|
| Compilation speed | Faster | Slower |
| Optimization depth | Lighter | Deeper |
| Profile data | Gathers it | Uses it |
| Main benefit | Progress sooner after startup | Steady-state performance |
These are design aims, not guaranteed results for every workload. The guide is for Java SE 8, where it says tiered compilation is the default for the server VM. Defaults, tier numbering, flags and compiler internals change between releases and vendors, so check the JVM Guide for the Java release you run. The current Java SE 26 JVM Guide (a March 2026 release) covers compiler control and HotSpot performance enhancements.
Rank #4
Seeing it on your own machine
You can inspect the layers yourself with standard JDK tools; exact output varies by version.
Quick Recap
Best Value
javap -c MyClassdisassembles a compiled class and shows the bytecode, which is whatjavacactually produced.java -Xint MyAppasks HotSpot to run in interpreted-only mode, which is handy for seeing how much the JIT contributes to speed.java -XX:+PrintCompilation MyApplogs methods as HotSpot compiles them. You will typically see only a fraction of your methods appear.
Common misconceptions
- “The JIT recompiles my Java source.” No. HotSpot works from loaded class and bytecode-level representations, not source files.
- “The CPU understands bytecode.” In the ordinary software path it doesn’t. The interpreter and generated native code are mechanisms the VM provides.
- “All time is spent in JIT-compiled bytecode.” Not necessarily. Oracle’s HotSpot FAQ notes that native methods and I/O, such as graphics or socket and database operations, can dominate an application’s time.
- “The spec requires a JIT.” It doesn’t; translation strategies are implementation choices.
- “This makes Java faster (or slower) than language X.” The mechanism doesn’t establish that. Comparisons need a stated benchmark, workload, runtime and machine.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
