I'm trying to understand the native implementation of the hashCode() method. What exactly does this method return? Is it a memory address or is it a random value?
-
4The OpenJDK sources should tell you. I doubt it's a memory address since the GC can move objects around in memory, it's probably some sort of internal object handle.millimoose– millimoose2013-04-19 13:11:59 +00:00Commented Apr 19, 2013 at 13:11
-
This is an excerpt of said code from around 2008: blogs.tedneward.com/…millimoose– millimoose2013-04-19 13:13:23 +00:00Commented Apr 19, 2013 at 13:13
-
And straight from the horse's mouth: hg.openjdk.java.net/jdk7/hotspot/hotspot/file/9b0ca45cd756/src/… The code looks the same to me as in the blog post.millimoose– millimoose2013-04-19 13:39:51 +00:00Commented Apr 19, 2013 at 13:39
-
2possible duplicate of What is an "internal address" in Java?assylias– assylias2013-04-19 13:42:55 +00:00Commented Apr 19, 2013 at 13:42
Add a comment
|
3 Answers
.hashCode() native implementation depends on JVM.
E.g. HotSpot has 6 Object.hashCode() implementations. You can choose it using -XX:hashCode=n flag running JVM via command line, where n:
0 – Park-Miller RNG (default)
1 – f(address, global_statement)
2 – constant 1
3 – Serial counter
4 – Object address
5 – Thread-local Xorshift
1 Comment
Boann
It's also interesting to note that because there is limited space to store things in the object header, the default hashcode is only 25 bits wide, not the full 32 bits of an int.
From the documentation:
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (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.)
So it may be related to a memory address, but it doesn't have to be - and you definitely shouldn't make any assumption about it being related to memory at all.
Nothing you do with a hash code should care about this at all. The only things you should infer from hash codes are:
- If the hash codes of two objects are the same, they may be equal objects
- If the hash codes of two objects are different, they are not equal objects (assuming a correct implementation, whether overridden or not)
7 Comments
millimoose
Considering GC, can the hash code even be the memory adress in the first place? For use in hash tables, it shouldn't really change unpredictably during execution.
Jon Skeet
@millimoose: It definitely can't be the current memory address in the face of a compacting GC. But it could be "the address at the time of first call, which is then remembered for later" perhaps. I try not to care too much :)
millimoose
Going by the old code excerpt I found, it definitely seems (insofar as I can read the somewhat hairy C) to be "some number that's determined once then saved". With six implementations available, including the initial memory address and a RNG.
millimoose
@GaborSch First of: hash codes aren't guaranteed to be unique. Second: the implementation might not really be used in a "real" VM, since it'd still have the problem where hash codes are adresses in the (relatively small) Eden Space.
gaborsch
@millimoose Sorry, I was wrong, uniqueness is not required at all. And if you have large enough Eden space (or whatever that JVM is using), the hash values may be well distributed.
|
Your answer lies here. As mentioned in the documentation:
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (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.)
