Project Lilliput

Project Lilliput is the OpenJDK project working on the size of the Java object header — the per-object bookkeeping the JVM stores in front of an object’s fields.

Every object on the heap carries a header holding its class pointer and its mark word, which the JVM uses for locking, identity hash codes and garbage collection metadata. On a 64-bit JVM that header has traditionally been 128 bits. For an object with two int fields, the bookkeeping is larger than the data.

Lilliput’s first deliverable, compact object headers, reduces the header to 64 bits by packing the class information into the mark word. It arrived as an experimental feature and was later enabled by default, having been measured across a wide range of workloads first. The saving is not dramatic per object — it is a few percent of heap on typical applications — but it applies to every object in the heap at once, and it is larger on workloads that allocate many small objects. Less heap in use also means less for the garbage collector to traverse, so throughput and pause times can improve alongside footprint.

This is the kind of change that has to be invisible to be useful. A smaller header changes object layout, which touches locking, hashing and every collector, so the work was gated behind a flag for several releases while those interactions were shaken out. Nothing in application code changes; the feature is a JVM flag and a measurement, not an API.

Longer term the project has explored shrinking the header further, to 32 bits.

More reading on Foojay:

• Does Java Really Use Too Much Memory? Let’s Look at the Facts (JEPs)
• Java 24 Rolls Out Today! Find Out Why It’s Aptly Named
• Here’s Java 25, Ready to Perform to the Limit

See Also

• The Heap, Stack and Metaspace
• Garbage Collection
• GC Algorithms: G1, ZGC and Shenandoah
• Value Objects (Project Valhalla)
• OpenJDK Projects