With -XX:hashCode=4
, HotSpot VM uses the address of the object when its identity hash code is first accessed, but only the lower 31 bits are used as the hashCode on LP64.
The example in this gist is:
A Groovy shell with -XX:hashCode=4
enabled, create a java.lang.Object
instance in it, and its identity hash code (0x5bde2768
) is shown in java.lang.Object@5bde2768
; a call to its hashCode()
method confirms the same value (0x5bde2768 == 1541285736). This is the lower-31 bits of the address of the object.
Without quitting the Groovy shell just yet, open up a CLHSDB (sun.jvm.hotspot.CLHSDB
), and use it to see how the hashCode relates to the address of the object instance. Using the command universe
, we can get the base address of the eden space, 0x0000000758600000
, and then replace the lower 31-bits of this address with the hashCode we saw from the Groovy shell session, we'd get 0x75bde2768
. Then use the inspect
command to see what's there, and look what we've got:
hsdb> inspect 0x75bde2768
instance of Oop for java/lang/Object @ 0x000000075bde2768 @ 0x000000075bde2768 (size = 16)
_mark: 394569148417