← Java Memory · guided lesson

What Happens in Memory

1 / 18 · story

the story

Call stack & heap

Every tool here exists because something was too slow or broke without it. Here is what.

1960 · Edsger W. Dijkstra

Early programs gave each subroutine one fixed block of working memory. A subroutine could not be called again before it finished, because the new call would overwrite the old one's data. In "Recursive Programming" (1960), written for ALGOL 60 compilers, Dijkstra kept each call's data on a stack instead: push a fresh area on every call, drop it on return. The JVM works the same way today: every thread has a stack of frames, and objects live on a shared heap.

the problem it solved

Let methods call each other, and themselves, without overwriting each other's local variables, and free that memory the instant a call returns.

why it matters: without it

Without a frame per call, no method could call itself, so no tree DFS and no backtracking. Without a heap, nothing could outlive the method that made it: no linked lists, no HashMaps.

sources: E. W. Dijkstra, "Recursive Programming", Numerische Mathematik 2 (1960) ↗ · JVM Specification (Java SE 17), §2.5 Run-Time Data Areas and §2.6 Frames ↗ · The java command (JDK 17): -Xss default thread stack size ↗

also in this chapter: References & pass-by-value · Fixed-width integers & overflow · Garbage collection