Project Lilliput would shrink Java object header

OpenJDK proposal to reduce the Java object header by half or more would lower memory and CPU usage on all Java workloads.

Project Lilliput would shrink Java object header

Java could get a smaller object header, thus improving memory usage, under a proposal being floated in the OpenJDK open source Java community this week. Known as Project Lilliput and led by Red Hat’s Roman Kennke, the effort would explore ways to shrink the object header, with a goal of reducing it to 64 bits.

Currently Java objects have a 128-bit object header in the 64-bit HotSpot VM, with a 64-bit multipurpose header word and a 64-bit class pointer. With average object sizes of five to six words, the current object header size is significant, the proposal states. Reducing header size would greatly reduce memory pressure, reducing overall CPU and memory usage for all Java workloads, whether in a large in-memory database or a small containerized application.

Specific benefits cited for Project Lilliput include:

  • Reduced heap usage.
  • Higher object allocation rate.
  • Reduced garbage collection activity.
  • Tighter packing of objects.

Other goals include making the header layout more flexible and allowing some build or even runtime configuration of how bits are used. As a secondary goal, it may be possible to reduce the object header to 32 bits. The proposal states that the object header has been used (and overloaded) for such purposes as indicating the locking state of an object, tracking the age of each object in garbage collection, storing identity hash code, and type information.

The proposal cites a number of techniques to explore for allocating and downsizing header fields, such as compressing pointers and backfilling fields known at compile time. There are constraints, though, such as requiring a change in assembly across supported platforms. There also might be issues with other Java projects, such as Panama, for bridging between Java and C/C++; Loom, intended to decrease complexity in concurrent applications; and Leyden, to address Java issues such as slow startup time.

The immediate goal of the initial work plan for Lilliput is to brainstorm, collect ideas, and devise a proof of concept as quickly as possible.

Copyright © 2021 IDG Communications, Inc.

How to choose a low-code development platform