How is a 32-bit hashCode stored in a 25-bit mark word in Java without data loss?

I've been looking into the internals of Java objects and am puzzled about how hashCode values are managed. As I understand it, the hashCode method in Java returns a 32-bit integer. However, this hashCode is stored in the object's header, specifically in the 25-bit mark word.

This raises a couple of questions for me:

How is it possible to store a 32-bit hashCode in a 25-bit mark word without losing some bits of data?
Even if data loss occurs due to this bit-length discrepancy, why is it that when I call hashCode() again, it still retrieves the original hashCode value without any apparent data loss?

Any insights into how Java manages to do this would be greatly appreciated.

First of all and most importantly: all of this is very much an implementation detail and not defined by the specification. I'm specifically discussing recent OpenJDK builds (I'm testing JDK 17, but this behaviour seems to exist for a while), but nothing says that other JDKs or even future versions of OpenJDK could change any of this.

Next it's important to distinguish an objects identity hash code from its hash code.

• the identity hash code is a value decided by the JVM that's constant over the lifetime of an object and can not be influenced by Java code (i.e. overriding hashCode() has no effect on this). This value can be gotten by calling System.identityHashCode(obj).

• the hash code on the other hand is what Java programmers mostly interact with: the return value of hashCode() when called on an object. While this is an important value whenever anything is stored in a HashMap or HashSet (or similar structures), the JVM itself does not particularly care about it. And even if it did, it couldn't store it in an object header, as hashCode() could conceivably return a different value every time it's called.

These two definitions interact in one important way: The hashCode() method of java.lang.Object (and thus also of any other object where that method isn't overridden) will return the identity hash code. So one could say that the identity hash code is the default value for the hash code, if nothing else is defined.

After looking at the relevant code it does indeed seem like there's at most 25 bits of space to store the identity hash code on 32bit platforms.

But hashCode is defined to be 32bits wide, so how can that be?

Simple: the identity hash code on those platforms simply never uses any more bits than 25, so all the bits that are not stored are known/assumed to be zero.

While I didn't find the specific place where that is decided (I also didn't look too closely), one can easily verify this with code like this:

public class MyClass {
    public static void main(String args[]) {
      int minLeadingZeroes = 32;
      for (int i = 0; i < 1_000_000; i++) {
          int hash = System.identityHashCode(new Object());
          minLeadingZeroes = Math.min(minLeadingZeroes, Integer.numberOfLeadingZeros(hash));
      }

      System.out.println("Smallest number of leading zeroes in identity hash codes of 1000000 objects = " + minLeadingZeroes);
    }
}

When run with a 64bit JVM this prints

Smallest number of leading zeroes in identity hash codes of 1000000 objects = 1

Whereas on a 32bit JVM it prints

Smallest number of leading zeroes in identity hash codes of 1000000 objects = 7

Granted, this is not absolute proof, but it would be extremely unlikely that those values are a coincidence when testing a million objects.

Also note that even in a 64bit OpenJDK build the identity hash code uses at most 31bits (as noted also in the comments of the implementation linked to above), despite there being plenty of spare room (many bits are unused in this case).