Java runtime field guide

Follow Java code through stack, heap and native memory.

This page connects an executable Java 17 example to the JVM specification and to a typical HotSpot implementation. Select code lines or memory regions to see what is stored, who owns it and when it can disappear.

Two lenses, one running program

The JVM specification defines the contract. HotSpot implements it. G1 manages its heap.

These are not two competing kinds of Java. They answer different questions about the same execution. Start with the specification to understand what every compliant JVM must provide, then move to HotSpot and G1 when implementation details affect real behaviour, diagnostics or performance.

01
Java programBytecode and application data
02
JVM specificationPortable rules and logical runtime areas
03
HotSpot JVMA concrete implementation of those rules
04
G1 garbage collectorOne HotSpot collector that manages the Java heap

View	What it is	What it explains	Use it when
JVM specification	The implementation-independent contract every compliant JVM follows.	Logical areas such as JVM stacks, heap, method area and runtime constant pools.	Learning fundamentals, reasoning portably, reading bytecode rules or discussing behaviour across JVM implementations.
HotSpot + G1	HotSpot is a JVM implementation. G1 is one garbage collector available inside HotSpot.	Metaspace, JIT code cache, object layout, native memory and G1 heap regions such as Eden, Survivor, Old and Humongous.	Operating a HotSpot process, reading GC logs, choosing JVM flags, investigating pauses, native memory or out-of-memory failures.

Practical rule: use the specification for what Java guarantees. Use the HotSpot + G1 view for how one widely used JVM delivers those guarantees. Other JVMs or collectors can implement the same contract differently.

Executable example

JvmMemoryLab.java

Java 17+

Select a line to trace its primary memory location.

Live architecture map

Where the runtime state lives

Logical model

Per threadPrivate execution state

Java heapShared, garbage-collected objects

Class-level runtime dataLogical JVM structures

Outside the Java heapTypical HotSpot native memory

Selected location

Java heap

Shared by all threads

What lives here

The lab instance, records, BigDecimal values, CompletableFuture, ConcurrentHashMap nodes, executor objects, Class mirrors and almost every other Java object or array.

Lifetime and management

Objects are reclaimed when the garbage collector proves that they are no longer reachable from GC roots.

Important nuance

Static fields are class state, but their exact storage is implementation-specific. Static references such as RECEIPTS still point to ordinary heap objects. HotSpot may also eliminate some allocations through escape analysis.

One execution path

What happens when execute() runs

01
Call and dispatch
The caller creates a frame. supplyAsync places heap-resident task state into the executor.
02
Worker execution
A pool thread creates its own execute-lambda frame and installs RequestContext in its ThreadLocalMap.
03
Allocation across boundaries
Records and wrappers use the heap, while the direct buffer payload uses native memory.
04
Resolution and optimisation
Runtime constants resolve symbols. Repeated hot execution may produce machine code in the JIT code cache.
05
Retention or collection
The static map retains the Receipt. Temporary task objects become collectible after references disappear.

Specification before folklore

Stack versus heap is the beginning, not the complete JVM memory model.

The JVM specification defines logical areas and deliberately leaves physical layout choices to implementations. HotSpot, OpenJ9 and different garbage collectors can realise those areas differently while preserving Java behaviour.