the JVM's memory map

the picture

you've seen "stack and heap" a hundred times. that's two boxes. a real JVM has closer to ten, and the other eight are why a container running -Xmx1g can still get killed for using too much memory.

think of the JVM as an office building. each thread is an employee with a private desk (their stack) and a sticky note saying what they're doing right now (the pc register). there's one big shared warehouse (the heap) where all the actual stuff is. there's a room full of blueprints that says what every kind of thing looks like (metaspace). there's a machine shop where the JIT keeps fast, pre-built versions of your hottest methods (the code cache). and then there's the building's own plumbing: the GC's bookkeeping, I/O buffers, symbol tables. nobody puts that in the brochure, but it's on the electricity bill.

notice the split. the top row is per thread: start a thousand threads and you get a thousand stacks. the middle is the heap, the only thing -Xmx limits. the bottom is native memory the JVM allocates for itself, mostly sized by other flags, some of it not sized by anything at all.

what the spec says, and what HotSpot does

the JVM spec lists six "run-time data areas". it says what each one is for, never where it lives. HotSpot (the JVM inside basically every JDK you'll download) maps them like this:

and two that the spec doesn't mention at all: the code cache (machine code from the JIT) and everything the garbage collector needs to do its job.

see it from the inside

the JVM reports its memory pools through java.lang.management. this lists them:

import java.lang.management.*;
 
void main() {
    for (MemoryPoolMXBean pool : ManagementFactory.getMemoryPoolMXBeans()) {
        long max = pool.getUsage().getMax();
        IO.println("%-9s %-34s max %s".formatted(
            pool.getType() == MemoryType.HEAP ? "heap" : "non-heap",
            pool.getName(),
            max < 0 ? "unlimited" : (max >> 20) + " MB"));
    }
}

on my machine (jdk 25, G1, 24 GB of RAM), sorted:

heap      G1 Eden Space                      max unlimited
heap      G1 Old Gen                         max 6144 MB
heap      G1 Survivor Space                  max unlimited
non-heap  CodeHeap 'non-nmethods'            max 5 MB
non-heap  CodeHeap 'profiled nmethods'       max 117 MB
non-heap  CodeHeap 'non-profiled nmethods'   max 117 MB
non-heap  Compressed Class Space             max 1024 MB
non-heap  Metaspace                          max unlimited

see the shape? the heap pools are named after the collector. run it with -XX:+UseSerialGC and you get Eden Space, Survivor Space and Tenured Gen instead. with -XX:+UseZGC: ZGC Young Generation and ZGC Old Generation. the heap's layout belongs to the GC. the non-heap pools don't change.

the 6144 MB is no accident either: with no -Xmx, the max heap is 25% of physical memory (-XX:MaxRAMPercentage=25). 24 GB / 4 = 6 GB.

reserved is not committed

here's the part that confuses everyone reading top. the JVM asks the OS for memory in two steps.

1. reserve: "please keep this range of addresses free for me." cheap. no memory is used, it's just a promise about addresses.
2. commit: "ok, now actually back these pages with memory." this is what costs RAM (and the OS only really hands over a page the first time something writes to it).

the JVM reserves big contiguous ranges at startup (the whole max heap, a gigabyte for class space, 240 MB for compiled code) and commits pieces as it grows.

two things jump out. the class space reserves a full gigabyte and uses a megabyte and a half (it has to be one contiguous range, so it grabs it all up front). and the GC's own structures are 62 MB, committed, for a 512 MB heap. that's memory you pay for that no heap graph will ever show you.