This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: deadlock detection
- From: Andrew Haley <aph at redhat dot com>
- To: Jacob Gladish <gladish at spinnakernet dot com>
- Cc: Jeff Sturm <jsturm at one-point dot com>, Tom Tromey <tromey at redhat dot com>, GCJ <java at gcc dot gnu dot org>
- Date: Fri, 5 Sep 2003 17:43:50 +0100
- Subject: Re: deadlock detection
- References: <Pine.LNX.4.44.0309042240470.32566-100000@ops2.one-point.com><1062770195.895.15.camel@gladish-pc.spinnakernet.com>
Jacob Gladish writes:
>
> And I'll second that vouch. We have an application with a large number
> of threads, and deadlocking the system is very easy to when a developer
> is even slightly careless with synchronized blocks. A simple singal to
> report the deadlocked condition would have saved us many hours of
> pouring over thread dumps.
>
> Maybe this could be something for me to contribute to the 3.3+ line.
This would be a useful addition to gcj.
> Is anyone interested in an offline discussion on this?
Yes, but I don't think it's necessary to take the discussion offline.
However, if that's what you want I'll gladly go along with your
wishes.
My understanding is that deadlock detection can be done with a
resource-allocation graph algorithm; you have to look for cycles in
the graph. Given that every synchronization calls _Jv_MonitorEnter,
it should be fairly easy to build such a graph. There's code to do
that here:
http://www.phfactor.net/code/dldet/
http://www.phfactor.net/code/dldet/deadlock.zip
On a related matter, there's an interesting paper at
http://www.acm.org/crossroads/xrds4-2/dynac.html.
Andrew.