Identity Hashcode to Java Object

Question

A friend of mine and I have the following bet going:

It is possible to get the Object again from the memory by using the Identity Hashcode received for that Object using System.identityHashCode() in Java. With the restriction that it has not yet been cleaned up by the Garbage Collector.

I have been looking for an answer for quite some while now and am not able to find a definite one.

I think that it might be possible to do so using the JVMTI, but I havn't yet worked with it.

Does anyone of you have an answer to that? Will buy you a coffie, if I can do so on your site ;)

Thanks in advance, Felix

p.s: I am saying this behaviour can be achieved and the friend of mine says it is not possible

Answer 1

In theory it is possible however you have some issues.

• it is randomly generated so it is not unique. Any number of objects (though unlikely) could have the same identity hash code.
• it is not a memory location, it doesn't change when moved from Eden, around the Survivors spaces or in tenured space.
• you need to find all the object roots to potentially find it.

If you can assume it is visible to a known object like a static collection, it should be easy to navigate via reflection.

BTW Once the 64-bit OpenJDK/Oracle JVM, the identity hash code is stored in the header from offset 1, this means you can read it, or even change it using sun.misc.Unsafe. ;)

BTW2 The 31-bit hashCode (not 32-bit) stored in the header is lazily set and is also used for biased locking. i.e. once you call Object.hashCode() or System.identityHashCode() you disable biased locking for the object.

Answer 2

I think your friend is going to win this bet. Java/the JVM manages the memory for you and there is no way to access it once you drop all your references to something.

Phantom References, Weak References, etc are all designed to allow just what you are describing - so if you keep a Weak or Phantom reference to something you can. identityHashCode is neither though.

C and C++ might let you do this since you have more direct control of the memory, but even then you would need the memory location not a hash of it.

Answer 3

No, because the identityHashCodes are not necessarily unique. They are not pointers to the objects.

Answer 4

No. The identityHashCode is not necessarily a memory address: it is only the default implementation of hashCode. It is also not guaranteed to be unique for all objects (but different instances should have different identityHashCodes).

Even if the identityHashCode is derived from a memory address, the object may be reallocated (but the identityHashCode cannot change, by definition).