Simple
No programming needed
A frame is the workspace of one method call. It holds the method's local variables and a small scratch stack for calculations, and it remembers how to get back to the caller.
An independent atlas of the Java Virtual Machine
Explore the machine behind every Java program.
Understand the Java Virtual Machine from the first instruction to the runtime systems that execute it.
- Java SE 25 specifications
- OpenJDK HotSpot, JDK 25
- Free and open source
- Works offline
Architecture
The whole machine on one plate
66 components, from the class file to the processor, drawn where they belong and connected by what flows between them. Select any part to see what it is.
Loading the map…
Three depths
One machine, explained at the depth you need
Every part has three explanations of the same facts. Choose your level from the menu at the top of any page; it applies everywhere. Here is the stack frame at each one.
Developer
Code, APIs and what you observe
A frame lives exactly as long as one method call. Its local variables are the method’s parameters and locals; javac works out how many slots and how deep an operand stack each method needs (locals= and stack= in javap -v).
That is why local variables vanish when a method returns, and why a lambda can only use local variables that never change after they are set (effectively final): it gets a copy of the value, not the frame’s slot.
Deep dive
Specification sections and HotSpot structures
JVMS §2.6: a frame is created each time a method is invoked and destroyed when the invocation completes, normally or abruptly. It contains a , an and a reference to the run-time constant pool of the current method's class (). Their sizes are fixed at compile time (max_locals, max_stack in the Code attribute: 3 and 3 for our main). Only one frame per thread is active: the current frame.
HotSpot's interpreter frame on x86-64 additionally stores the sender's stack pointer, the Method*, the class mirror, the profiling pointer (mdp), the constant pool cache, the locals pointer, the bcp and a monitor block. Compiled frames look different again: values live in registers and one physical frame can represent several inlined methods.
Subsystems
Seven areas, from source code to processor
- Build time3 parts inside · outside the JVMBefore the JVM starts, a compiler turns source files into .class files that hold bytecode: javac for Java (other JVM languages have their own compilers).
- Class loading12 parts insideThe class loader finds class files and turns them into classes the JVM can use.
- Memory15 parts insideRuntime memory holds what a running program needs: objects, method calls in progress and class information.
- Execution engine9 parts insideThe execution engine runs bytecode instructions, and compiles busy code into machine code.
- Garbage collection11 parts insideThe garbage collector finds objects the program can no longer reach and reclaims their memory.
- Native interface1 parts insideThe native interface lets Java call code written for the operating system, such as C libraries, and lets that code call back.
- Platform4 parts inside · outside the JVMThe operating system and processor that the JVM itself runs on.
Start here
Follow one line of Java to the processor
What happens when you run a Java program? Seven short chapters, about 21 minutes, no programming knowledge needed. Each one asks you to predict, shows you what really happens, and checks that it made sense.
Begin the first lesson- 1Your first Java programWhat is a Java program, before anything runs?
- 2The compilerHow does Hello.java become something the JVM can run?
- 3The JVMWhat is the JVM, and why does Java need one?
- 4Loading classesHow does the JVM get Hello.class ready to run?
- 5MemoryWhen your program creates an object, where does it go?
- 6ExecutionHow does the JVM actually run the bytecode?
- 7Garbage collectionWhat happens to objects your program no longer uses?
System.out.println("");
Type anything you like between the quotes, then press Run it to follow your line from the compiler to the processor.
Exhibits
Watch it run, then look inside
Step through real programs with their verified javap output, or open a part and see its internal structure.
- Walkthrough · 8 stepsFrom
java Mainto the first bytecodeCompilation, JVM creation, core classes, loading and initializing the main class, and the first frame. - Walkthrough · 10 stepsExecuting
new Person("Alex")One statement, instruction by instruction: resolution, class loading, allocation, the operand stack, a constructor frame, and references. - Look inside a partInside the heapShared memory for all class instances and arrays, reclaimed automatically by the garbage collector.
- Walkthrough · 8 stepsA hot method becomes machine codeInterpreter counters, tier-3 C1 code with profiling, tier-4 C2 code, on-stack replacement, and the deoptimization safety net.
- Look inside a partInside the stack frameStorage for one method invocation: local variables, operand stack and a link to the class's constant pool.
- Walkthrough · 7 stepsA young collection in G1Allocation in eden, a stop-the-world evacuation pause, roots, copying live objects, and freeing whole regions.
Accuracy
Simple is short, never false
Every simplified picture says what it leaves out, and every analogy says where it stops being true. Bytecode, logs and numbers come from running a real JDK (OpenJDK 25.0.4), never from memory.
What the Java specification requires is kept apart from how OpenJDK’s HotSpot JVM happens to do it, and the drawings say which is which:
- Specification: what every JVM must do
- HotSpot: how OpenJDK’s JVM does it (marked HS)
- Platform and build time: outside the JVM
Every claim cites its source: 123 primary sources, from the Java SE 25 specifications to the OpenJDK source code. Browse the references or read the accuracy policy.
The project
Independent, free and open
JVM Atlas has no accounts, no tracking and no backend: your progress stays in your browser. The content and code are open source, and corrections are welcome.