Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · senior level

Describe the JVM's runtime data areas. What lives on the stack vs the heap vs Metaspace?

🎤 Say this first

Per-thread: the JVM stack (a frame per method call holding locals and operand stack) and the PC register. Shared: the heap (all objects, GC-managed) and Metaspace (class metadata, in native memory — the PermGen replacement since Java 8). Key rule: objects always live on the heap; only references and primitives live in frames. Frames are freed by returning, objects by GC.

The full picture

🎬 JVM runtime data areas

1 / 6
Per thread 🧵PC registerJVM stackHeap (shared) 📦MetaspaceOrder.classmethodsstaticsStack = automatic, per-thread, fast. Heap = shared, GC-managed. Metaspace = class metadata in native memory.

The JVM's runtime data areas: a shared Heap and Metaspace, plus per-thread areas — the JVM stack (one frame per method call) and program counter.

Frames push and pop; objects are born on the heap; classes live in Metaspace.
  • JVM stack — one per thread (default ~512KB–1MB, -Xss). Deep recursion → StackOverflowError. Allocation/free is pointer arithmetic — this is why locals are cheap.
  • Heap — shared object space (-Xms/-Xmx), internally generational for most collectors. Exhaustion → OutOfMemoryError: Java heap space.
  • Metaspace — class metadata in native memory, grows dynamically (MaxMetaspaceSize to cap). Leaking classloaders (hot redeploys!) → OutOfMemoryError: Metaspace.
  • Code cache — JIT-compiled native code; direct memory — NIO buffers outside the heap (watch it in container limits).

🔄 Likely follow-up questions

  • What is the string constant pool, and where do interned strings live? (heap, since Java 7)
  • What triggers OutOfMemoryError: Metaspace in an app-server environment?
  • How does escape analysis interact with synchronization (lock elision)?