JDK-8015828 : Compact Object Headers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2013-05-31
  • Updated: 2025-06-27
  • Resolved: 2018-08-28
Related Reports
Duplicate :  
Description
Object headers consume 14% of the average heap dump (assuming a 32-bit JVM with 8-byte headers).  64-bit JVMs will have a larger impact.  The values in the object header should be trimmed to get down to 4-byte headers.

Identity hash codes could be moved to a WeakHashMap<Object, Integer>.  This will make lookup of identity hash code slower.  I assume identity hash codes aren't used very much.  If so, then making the operation slower won't have a significant impact.

GC age can be removed.  Instead of storing the age in the objects, let's be smarter on how we organize the young generation.  For G1 GC, the region should track the age of the objects.  When sweeping objects, they should be moved to a region of the appropriate age.  For CMS, the survivor space should order the objects by age and keep pointers to the beginning of each age group.  Newly created objects go at the end of the list.  In a sense, the survivor space acts like a queue.

The JavaThread* and 3 lock flags can probably be removed if biased locking is no longer being used.  If lock ownership is needed for thin/stack locks, a WeakConcurrentHashMap<Object, Thread> can be maintained to track lock ownership.

That leaves the Klass*.  This can be turned into a 32-bit array index.
Comments
Triage: This is not on our current list of priorities. We will considered this feature if we receive additional customer requirements.
28-08-2018

There are several use cases where the heap size is so prohibitive that many cores are sitting idle. So, slowing down threads is actually a possibility since the application server can simply run more threads to utilize more cores. If there were a command-line JVM switch that could adjust the header size for performance or space, that would definitely be useful. There are many more use cases where the heap size is large but the cores are all busy. So, slowing down threads is not an option. However, reducing the used heap size will lower the impact from GC and help average response times. In this case, reducing the header size can help if done carefully. It has to be done in a way that performance isn't made worse. Maybe the route forward is to provide the command-line option with a rudimentary implementation that works. Then, spend more time working on improving the mechanisms so that 4-byte headers can be defaulted on.
04-06-2013

All of this is possible if you do not care about performance at all. FYI Fast-locking pre-dates biased-locking.
04-06-2013