Java 24 to Reduce Object Header Size and Save Memory

Part of this complexity comes from what IMO was a mistake on Java's design (which was AFAIK copied by C#): the base Object class does too much. It has equality comparison, string conversion, object hashing, and a per-object re-entrant lock. Other than equality comparison (which is also bad because it contributes to the perennial confusion between identity equality and value equality), these need extra storage for each and every object in the system (string conversion contains the object hash code as part of its default output). Some tricks are used to avoid most of the space overhead for the per-object lock, at the cost of extra complexity.

For more information, there&#x27;s a recent talk on Project Lilliput by Roman Kennke: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=kHJ1moNLwao" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=kHJ1moNLwao</a>.

&gt; This means that [with Compact Object Headers] the number of different class types we can load into a JVM process is [reduced to] around ~4 million [from previously 4 billion].<p>Comparing the class count of some of today’s Java projects (including dependencies) to two decades ago, I wonder if we won’t risk hitting that limit in another two decades or so, and then revert back to the bigger header size again. ;).

&gt; This is lightweight, by way of comparison: until quite recently, Python&#x27;s header tax was 308 bytes<p>Really? I thought that PyObject_HEAD only contains two machine words.

I always kind of found it interesting that specifying the size of object fitters was part of the JVM specification. This sort of seems like an arbitrary implementation detail, since the programmer will never have to know anything about it.