Will .hashcode() return a different int due to compaction of tenure space?

by

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

In fact, an identityHashCode implementation has to behave this way to satisfy the following part of the general hashCode contract:

“Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.”

A hypothetical implementation of identityHashCode() that simply returned the current machine address of an object would violate the highlighted part if/when the GC moved the object to a different address. The only way around this would be for the (hypothetical) JVM to guarantee that an object never moves once hashCode has been called on it. And that would lead to serious and intractable problems with heap fragmentation.

More Related Contents:

  1. How ‘random’ is allocation of memory when I say “new Integer” in Java?
  2. Why is it bad practice to call System.gc()?
  3. When is the finalize() method called in Java?
  4. Can java finalize an object when it is still in scope?
  5. Does GC release back memory to OS?
  6. Is there a destructor for Java?
  7. Are static fields open for garbage collection?
  8. Garbage collection of String literals
  9. Java garbage collector – When does it collect?
  10. Circular References in Java
  11. Garbage collection on a local variable
  12. Android – Activity Constructor vs onCreate
  13. How can I avoid garbage collection delays in Java games? (Best Practices) [closed]
  14. Which loop has better performance? Why?
  15. When and how are classes garbage collected in Java?
  16. When Is The Object Eligible For Garbage Collection?
  17. Size of Huge Objects directly allocated to Old Generation
  18. Java still uses system memory after deallocation of objects and garbage collection
  19. Thread Caching and Java Memory model
  20. Why does the JVM require warmup?
  21. Garbage collection on intern’d strings, String Pool, and perm-space
  22. How does Java Garbage collector handle self-reference?
  23. Do anonymous classes *always* maintain a reference to their enclosing instance?
  24. In Java is Permanent Generation space garbage collected?
  25. How do you Force Garbage Collection from the Shell?
  26. Is the garbage collector guaranteed to run before Out of Memory Error?
  27. How to make a long time Full GC in Java manually
  28. Default garbage collector for Java 8
  29. Measuring time spent on GC
  30. When does Java’s garbage collection free a memory allocation?

Leave a Comment