BrewlearnJVM architecture in Java
Class loader subsystem, runtime data areas, execution engine.
java -jar app.jar and a web server comes alive. But your CPU has never heard of Java. So who is actually running your code?A program that runs programs
The JVM is itself a native program, built separately for each OS and CPU. It never reads your .java files. javac first compiles them into bytecode (.class files), and the JVM's whole job is to load and execute that bytecode.
javac Main.java // source -> Main.class
java Main // JVM runs the bytecodeFour departments
Inside the JVM: the class loader subsystem finds, loads, links and initializes classes. The runtime data areas are memory: heap, stacks, metaspace, PC registers. The execution engine interprets and JIT-compiles bytecode (and runs the GC). The native interface (JNI or the FFM API) bridges Java to C libraries.
Where does the verifier live?
Before any class runs, the bytecode verifier checks that it's safe and well-formed. Is the verifier a memory area like the heap?
Think about it, then reveal the answer
No. Verification is a step of class loading (the linking phase). Heap, stacks and metaspace are runtime data areas: places where data lives, not checks that run.
Interpret first, compile later
The execution engine starts by interpreting bytecode, so your app launches right away. Meanwhile it counts which methods run a lot. Those hot methods get compiled by the JIT into native machine code. Compiling everything up front would make startup slow, and the JIT would have no profiling data to guide its choices.
Same JAR, two machines
The exact same app.jar runs on a Linux server and on a Mac laptop. Which part is platform-specific?
The bytecode inside the JARThe JVM itselfNothing: Java is interpreted from source
Show the answer
The JVM. Bytecode is platform-neutral; each platform gets its own JVM build that understands it. That's write once, run anywhere.
The source-file shortcut
Since Java 11 you can run java Main.java directly. It looks like the JVM reads source, but it doesn't: the launcher compiles the file in memory and then runs the bytecode as usual. The JVM only ever executes bytecode.
java Main.java // compiled in memory firstReading a crash by department
Knowing the departments tells you where to look. ClassNotFoundException or NoClassDefFoundError: the class loaders. OutOfMemoryError or StackOverflowError: the runtime data areas. Slow first requests after a deploy: the execution engine still warming up its JIT. Most of this world is a deeper tour of each department.
Key takeaways
- Class loader subsystem: find, load, link and initialize classes
- Runtime data areas: heap, stacks, metaspace, PC registers
- Execution engine: interpreter, JIT compilers and garbage collector
- Native interface (JNI / FFM API) bridges to C libraries
💡 The JVM is a theatre: loaders bring in the scripts, the stage and storage rooms are memory, and the actors (execution engine) perform.
The JVM specification doesn't require a JIT or any particular garbage collector. A JVM that only interprets is still valid. HotSpot, the JVM you most likely use, is named after its trick of finding the code "hot spots" worth compiling.
Practice questions
Which part of the JVM turns frequently executed bytecode into native machine code?
- Metaspace
- The class loader
- The bytecode verifier
- The JIT compiler in the execution engine
Check your answer
The JIT compiler in the execution engine. The execution engine first interprets bytecode, then its JIT compilers (C1/C2) compile hot methods to machine code for speed.
The exact same app.jar runs unchanged on a Linux server and a Mac laptop. What makes this possible?
- The JAR contains its own copy of the JVM
- Java source is shipped and interpreted line by line
- javac stores a separate binary for each OS inside the JAR
- Platform-neutral bytecode is run by a JVM built for each platform
Check your answer
Platform-neutral bytecode is run by a JVM built for each platform. Bytecode is the same everywhere; the platform-specific part is the JVM itself. That is the 'write once, run anywhere' idea.