Re: Distinct ID Number Per Object?
Tom Hawtin wrote:
Mark Thornton wrote:
Twisted wrote:
Regarding identityHashCode() -- I have it on good authority than the
Sun JVM implementation, and the typical implementation, uses the RAM
address of the object's handle (which isn't moved by compacting gc).
I don't think the Sun JVM's have used object handles for many years.
The early garbage collectors did work that way.
Absolutely.
Handles were briefly resurrected for the earliest HotSpot
implementations. On typical, modern, serious Java implementations,
objects do get moved in memory and have no fixed handles.
Even for 32-bit JVMs, identity hash codes do clash. If you look at the
values produced, they clearly aren't sensible addresses - odd numbers,
for instance. I believe that it is true that values are typically
*derived* from the address of the object at the time the hash is first
requested.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321873
I can't believe this nonsense keeps turning up...
Excellent link, and an interesting little program that proves the point that
It appears straightforward to find two live objects sharing the same identityHashCode, using only a bog standard JRE. Real implementations with unique identityHashCodes for live objects, I would expect to be confined to legacy J2ME JVMs (if they had System.identityHashCode).
It seems so clear /a priori/ that hashCode() return values and so-called
"internal addresses" are such completely different beasts in such completely
different worlds that no one should be able to confuse the two. It's also
curious that people focus on the phrase "the internal address of the object"
and not "converting ... into an integer" in the Javadoc description:
This is typically implemented by converting the internal address of the object into an integer,
but this implementation technique is not required by the JavaTM programming language.
Really, that part of the Javadoc description should just be deleted. In fact,
they should get rid of
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.
It is imprecise and misleading. What they should say is something like, "A
good hash code approaches uniform distribution of values across the int range."
--
Lew