Stack and Heap

Why this matters

• StackOverflowError and OutOfMemoryError are both memory failures, and the one you get tells you exactly which region filled up.
• Thread safety only exists as a concern because stacks are private and the heap is shared.
• Every later topic — garbage collection, memory leaks, escape analysis — assumes you can place a given value in the right region.

The two regions

Placing a value

public class Demo {
    private int instanceField = 10;          // heap, inside the Demo object
    private static int staticField = 20;      // heap, with the class metadata

    public void process(int parameter) {      // stack — a copy of the argument
        int local = 5;                         // stack — the value itself
        String text = "hello";                 // stack holds the reference; the String is in the pool
        int[] numbers = new int[3];            // stack holds the reference; the array is on the heap
        Demo other = new Demo();               // stack holds the reference; the object is on the heap
    }                                          // the whole frame is popped here
}

Frames and the call chain

Each method call pushes a frame. Each return pops one. The chain of frames is precisely what a stack trace prints.

void a() { b(); }
void b() { c(); }
void c() { throw new IllegalStateException("here"); }

// Stack when the exception is thrown, top first:
//   c()   ← throw site
//   b()
//   a()
//   main()

Unbounded recursion never pops, so the stack fills:

static int recurse(int n) {
    return recurse(n + 1);        // StackOverflowError after a few thousand frames
}

The depth you reach depends on the frame size and the thread's stack size, set with -Xss. Raising it delays the error; it does not fix a missing base case.

Why thread safety exists

public class Counter {
    private int count = 0;                  // heap — shared by every thread

    public void increment() {
        int local = count;                   // stack — private to this thread
        local = local + 1;
        count = local;                        // writes back to shared memory
    }
}

Two threads each have their own local. Both may read count as 5, compute 6, and write 6. One increment is lost. The locals were never the problem; the shared heap field was.

This is the reason a method using only locals is automatically thread-safe, and why anything touching instance or static state needs thought.

Escape analysis

The JIT compiler can sometimes prove an object never leaves the method that created it, and then allocate its fields directly in the frame — scalar replacement — avoiding the heap entirely.

public double distance(double x1, double y1, double x2, double y2) {
    Point from = new Point(x1, y1);       // may never reach the heap at all
    Point to = new Point(x2, y2);
    return from.distanceTo(to);
}

Because neither Point is stored, returned or passed to unknown code, the JIT may eliminate both allocations. This is why writing small short-lived helper objects for clarity is usually free in practice.

Reading the two errors

The last row connects back to the first column: each thread needs its own stack, so thread count and stack size multiply. Ten thousand threads at 1 MB each is 10 GB of stack memory before a single object is allocated — which is precisely the constraint virtual threads were designed to remove.

Common misreadings

• "Primitives are always on the stack." A primitive local is. An int instance field lives on the heap inside its object.
• "The reference and the object are in the same place." The reference is in the frame; the object is on the heap. This is the whole distinction.
• "Each thread gets its own heap." Only stacks are per-thread. One shared heap is why synchronisation exists.
• "Strings are on the stack because they look like values." String is an object. The pool is a region of the heap.
• "Raising -Xss fixes a StackOverflowError." It delays it. Fix the recursion.
• "OutOfMemoryError always means a leak." It may mean an undersized heap or a legitimately large working set. The heap dump tells you which.