views:

89

answers:

5

If I call hashcode() method on some oject it returns the internal address of the object(default implementation) . Is this address logical one or physical address.

In garbage collection, due to memory compaction objects shifting takes place in the memory. If I call hashcode before and after the GC, will it return the same hashcode (it returns) and if yes then why(because of compaction address may change) ?

A: 

In this link it says that indeed the default hash code is the JVM address of the object, but if it is moved - the address stays consistent. I don't know how reliable this source is, but I am sure that the implementors of this method thought of this scenario (which is not rare or corner case), and ensured correct functionality of this method.

duduamar
Not a reliable source. Riddled with errors. You shouldn't rely on *any* third party sites when you have the Javadoc: that's what it's for.
EJP
+2  A: 

No, the default hash code of an object will not change.

The documentation doesn't say that the hash code is the address, it says that it is based on the address. Consider that hash codes are 32 bits, but there are 64-bit JVMs. Clearly, directly using the address wouldn't always work.

The implementation depends on the JVM, but in the Sun (Oracle) JVM, I believe the hash code is cached the first time it's accessed.

erickson
From Java Doc of hashCode: This is typically implemented by converting the internal address of the object into an integer
@erickson - actually, the hashcode is cached when the GC relocates an object ... if `hashcode()` has previously been called.
Stephen C
A: 

if the hashcode changes, the object will disappear in a hash set which it was inserted into, and Sun will be flooded with complaints.

irreputable
A: 

By the contract of hashCode it cannot change for such a reason.

EJP
+3  A: 

@erickson is more or less correct. The hashcode returned by java.lang.Object.hashCode() does not change for the lifetime of the object.

The way this is (typically) implemented is rather clever. When an object is relocated by the garbage collector, its original hashcode has to be stored somewhere in case it is used again. The obvious way to implement this would be to add a 32 bit field to the object header to hold the hashcode. But that would add a 1 word overhead to every object, and would waste space in the most common case ... where an Object's hashCode method is not called.

The solution is to add two flag bits to the object's flag word, and use them (roughly) as follows. The first flag is set when the hashCode method is called. A second flag tells the hashCode method whether to use the object's current address as the hashcode, or to use a stored value. When the GC runs and relocates an object, it tests these flags. If the first flag is set and second one is unset, the GC allocates one extra word at the end of the object and stores the original object location in that word. Then it sets the two flags. From then on, the hashCode method gets the hashcode value from the word at the end of the object.

Stephen C