Deadlock detection mechanism incorrectly assumes that thread cannot block itself

[Dmytro Sheyko]

David,

Well, this change is also a bit about code cleanup. Currently we handle cycle with single thread differently. Why? What is so special about single thread cycles to ignore them?

Can it be useful not to ignore them and treat as usual thread cycles? I think yes. For example, one can decide to prefer their own non-reentrant lock to standard ReentrantLock in order to achieve better performance.

Of course, after the change numerous deadlock cases will still remain uncovered. And I doubt that all cases will be covered in future. As instance, AbstractOwnableSynchronizer supports only single owner thread and Thread supports only single blocker. So the case, where single writer is blocked by two readers and these readers are both blocked by that writer, cannot be detected without total rework of deadlock detection code. But the more problematic cases is covered the better.

Regards,
Dmytro

> Date: Wed, 28 Nov 2012 12:53:38 +1000
> From: david.holmes at oracle.com
> To: dmytro_sheyko at hotmail.com
> CC: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: Re: Deadlock detection mechanism incorrectly assumes that thread cannot block itself
> 
> On 28/11/2012 2:10 AM, Dmytro Sheyko wrote:
> > Hi,
> >
> > One more patch regarding deadlock detection.
> > https://bugs.openjdk.java.net/show_bug.cgi?id=100059
> >
> > Deadlock detection mechanism assumes that thread cannot block itself. In
> > general this is not right, especially in case of non-reentrant mutexes.
> 
> Arguably that is not a deadlock per se. I'm unclear in your patch as to 
> what conditions actually constitute a self-deadlock and how it is 
> detected. For example:
> 
> Locksupport.park(); // if no one knows to unpark me I never return
> 
> Object o = new Object();
> synchronized(o) { o.wait(); } // can't get notified
> 
> CountdownLatch l = new CountdownLatch();
> l.await(); // no one can count down
> 
> Should these be reported? I don't see how they could without much more 
> elaborate analysis of the objects involved. So what constituates a 
> detectable self-deadlock?
> 
> Thanks,
> David
> 
> 
> > One of such examples we can find here (FIFOMutex sample):
> > http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html
> >
> > To fix this, we just need to drop unnecessary code.
> >
> > Attached updated patch and testcase
> >
> > Thanks,
> > Dmytro
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121128/cde9ab93/attachment.html