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: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: Jacob Gladish <gladish at spinnakernet dot com>, Jeff Sturm <jsturm at one-point dot com>, Tom Tromey <tromey at redhat dot com>, GCJ <java at gcc dot gnu dot org>
- Date: Sat, 6 Sep 2003 10:40:30 +0100
- Subject: RE: deadlock detection
- References: <75A9FEBA25015040A761C1F74975667D014422EB@hplex4.hpl.hp.com>
Boehm, Hans writes:
> I think that if you want to detect deadlocks on the fly, you really
> only have to check as you are about to lock a heavyweight lock.
> And then it suffices to do a depth-first search of only the
> heavyweight locks reachable from the one we're trying to acquire.
Oh, of course! Thanks Hans.
That's obvious, but for some reason I didn't think of it -- you only
have to look at the part of the graph you changed.
> 1) This is typically very cheap, since you only pay on persistent
> 1) contention, and there probably aren't very many heavyweight
> 1) locks.
>
> 2) There are probably weird cases for which it's expensive. It
> 2) probably shouldn't be the default.
>
> It seems to me that the result is still quite limited though, since
> it only detects deadlocks involving exclusively locks, as opposed
> to wait/notify or more obscure dependencies (IO, wait loops on
> volatiles, etc.) My guess is that this covers around half the half
> the Java deadlocks I've seen, though my experience may be atypical.
That's a useful insight.
Andrew.