4

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

Rittel
  • 579
  • 5
  • 21

4 Answers4

7

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
1

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.

Tim B
  • 40,716
  • 16
  • 83
  • 128
0

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

Boann
  • 48,794
  • 16
  • 117
  • 146
0

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).

Javier
  • 12,100
  • 5
  • 46
  • 57
  • 1
    The hash code doesn't change when an object is moved between generations so you can assume it is not a memory address. ;) – Peter Lawrey Dec 18 '13 at 10:27
  • Right. I wrote that only because I wanted to address explicitly the comment on the documentation of Object.hashCode that "this is typically implemented by converting the internal address of the object into an integer". – Javier Dec 18 '13 at 10:41
  • 1
    My point being that the "internal address" doesn't correspond to any actual address. You can prove that objects with the same address e.g. after a GC they are at the bottom of the Eden space and you can show they have the same address, but they have different hash code each time. – Peter Lawrey Dec 18 '13 at 10:57