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