Understanding JVM Memory Structure and Object Lifecycle

The JVM memory is divided into several regions: the heap stores object instances and arrays; the virtual machine stack holds stack frames with a local variable table , operand stack, dynamic linking information, and return address; the native method stack serves native (C/C++) calls; the method area (implemented as Permanent Generation or Metaspace) contains loaded class metadata, static variables, and compiled code; and the program counter, a small thread‑local space indicating the current bytecode line.

Heap memory follows the generational collection theory, split into young and old generations. The young generation consists of the Eden space and two survivor spaces (S0 and S1, also called From and To). By default, the old generation occupies two‑thirds of the heap, while the young generation occupies one‑third. Objects are initially allocated in Eden, then promoted to survivor spaces and eventually to the old generation based on survival thresholds such as -XX:MaxTenuringThreshold .

Heap size defaults to 1/64 of the physical memory for the initial size and 1/4 for the maximum size, but can be tuned. The JVM also distinguishes between symbolic references stored in the constant pool and direct references resolved at runtime through static resolution or dynamic linking.

Object creation follows a multi‑step process: constant‑pool lookup, class loading if necessary, memory allocation (via pointer bumping in the young generation or free‑list allocation in the old generation), zero‑initialization, and setting of object header information (hash code, GC age, lock state). Objects are initially placed in Eden; when Eden fills, a minor GC copies surviving objects to a survivor space, and repeated copying eventually promotes them to the old generation, triggering full GCs when the old generation becomes full.

Object memory layout consists of an object header (containing runtime data, type pointer, and lock information), instance data (the actual fields), and alignment padding to ensure 8‑byte alignment. Access to objects can be performed via handles (indirect references stored in a handle pool) or direct pointers (the reference directly holds the object address), with the latter offering faster access.

Java defines four reference types to influence garbage‑collection behavior: strong references (prevent collection), soft references (collected only before an OutOfMemoryError, useful for caches, created via SoftReference ), weak references (collected on any GC cycle, created via WeakReference ), and phantom references (used with a ReferenceQueue to track object finalization). These mechanisms allow developers to control object lifecycles and memory usage effectively.