Understanding Java Object Memory Layout with JOL

Java developers frequently create objects using new , reflection, cloning, or deserialization, but the internal memory representation of these objects is often opaque. This article explores the composition of a Java object in the heap, showing that each object consists of three parts: the object header, instance data, and alignment padding.

1. Object Memory Structure Overview – After a class file is loaded into the method area and the main method is invoked, a reference is allocated on the stack while the actual object resides on the heap. The article provides a diagram of the three components and briefly describes their roles.

2. JOL Tool Introduction – The OpenJDK jol (Java Object Layout) library can print the internal layout of objects. Add the dependency to Maven:

org.openjdk.jol
jol-core
0.14

Use VM.current().details() to see JVM configuration (64‑bit, compressed oops, 8‑byte alignment) and ClassLayout.parseInstance(obj).toPrintable() to print an object's layout.

3. Object Header – The header contains a 64‑bit mark word and a klass pointer (4 bytes with compressed oops, 8 bytes otherwise). For arrays, an additional 4‑byte length field is present. Example code prints the layout of an empty User class:

public class User {}

The printed layout shows 8 B mark word + 4 B klass pointer + 0 B instance data + 4 B padding = 16 B total.

3.1 Mark Word – Stores runtime state, lock information, hash code, and biasing data. The article walks through lock escalation (no‑lock → biased → lightweight → heavyweight) with synchronized blocks and shows the corresponding mark‑word bits before and after locking using JOL output.

3.2 Klass Pointer – Points to class metadata in the method area. With compressed oops it occupies 4 B; without compression it occupies 8 B. The article demonstrates the size change by disabling compression via -XX:-UseCompressedOops .

3.3 Array Length – For array objects, the header stores the element count (4 B). A short example creates User[] user = new User[2]; and prints the layout, showing mark word, klass pointer, length, and the reference slots.

4. Instance Data – Holds the actual field values. Primitive types have fixed sizes (byte/boolean 1 B, char/short 2 B, int/float 4 B, long/double 8 B). Reference fields occupy 4 B with compressed oops or 8 B otherwise.

4.1 Field Reordering – The JVM reorders fields to reduce padding: larger types first, then smaller types, aligning each field to its natural size. The article shows a User class with mixed primitives and the resulting layout, explaining pre‑padding and post‑padding.

4.2 Inheritance – Fields from super‑classes appear before subclass fields. The article provides examples of classes A and B extends A and shows how padding is inherited.

4.3 Reference Types – By default, primitive fields are placed before reference fields; this order can be changed with -XX:FieldsAllocationStyle=0 .

4.4 Static Variables – Static fields are stored in the class metadata, not in the object layout, so they do not affect object size.

5. Alignment Padding – HotSpot requires object sizes to be a multiple of the alignment (default 8 bytes). If the sum of header and instance data is not aligned, padding bytes are added. The article shows how changing the alignment to 16 bytes ( -XX:ObjectAlignmentInBytes=16 ) increases the padding.

6. Summary – By using JOL, developers can visualize object layouts, understand lock state transitions, evaluate the impact of compressed oops, and estimate memory consumption for tuning JVM parameters and preventing excessive GC.