Identity Hash Code as Object ID

At our meeting today, Corky again reminded me that it is ok to just come up with an approximation, and then later, in case of a false positive, check if a deadlock has actually occurred. That may make it possible to use System.identityHashCode(Object x) for the cases in which I currently can’t assign a unique ID. The identity hash codes of objects are not guaranteed to be unique, but most of the time, this is actually true. It is guaranteed that the identity hash code remains the same for an object’s entire lifetime, though. As a result, if identity hash codes are used, I will always be able to detect a deadlock if one has occurred; if two distinct objects happen to have the same hash codes, then a deadlock might be reported even if there isn’t one. The detector might have false positives.

I should be able to recognize a false positive on the master side, though, simply by checking if the thread that closed the apparent cycle in the wait graph at the SP\_TRYMONITORENTER sync point was able to continue past the monitorenter instruction and reached the SP\_MONITORENTER sync point. If that was the case, then a false positive was reported.

The JDI ThreadReference class also has two methods, public ObjectReference currentContendedMonitor() and public List<ObjectReference> ownedMonitors(), and I could just let the program continue for a few milliseconds after detecting a possible deadlock when a thread reaches the SP\_TRYMONITORENTER sync point, and then see if the thread’s current contended monitor is among the owned monitors of the other threads involved in the potential deadlock.

With identity hash codes, I’ll have the same problem as with using the class index as object ID that I had described earlier: If I use the identity hash code, I have to distinguish those from actual unique IDs. The identity hash code is only an int (and seems to always be non-negative), though, so it could be mapped into the negative range of the object ID, which is a long. I cannot use the identity hash code and the class index at the same time, but the identity hash code seems to be the better option anyway,

So I guess I’ll replace the implementation of java.lang.Object.$$$getObjectID$$$ from returning -1 to returning a bit-twiddled System.identityHashCode(this).


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply