This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: deadlock detection
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Jacob Gladish'" <gladish at spinnakernet dot com>,Andrew Haley <aph at redhat dot com>
- Cc: "Boehm, Hans" <hans_boehm at hp 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: Mon, 8 Sep 2003 09:53:49 -0700
- Subject: RE: deadlock detection
> -----Original Message-----
> From: Jacob Gladish [mailto:gladish@spinnakernet.com]
>
> > Boehm, Hans writes:
> > > 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.
> I hadn't considered the ability to do any analysis other then
> exclusive
> locks. Do any other java implementations attempt to do this?
>
I don't think that's really possible. If you're
waiting with Object.wait(), you really don't know which thread you're
waiting for. (I guess you can detect if all threads are waiting on a lock
or untimed Object.wait(), but I suspect there are usually daemon threads
around that wake up occasionally even if the application is really completely
deadlocked.)
Probably the best you can do for the more complex deadlocks is to
print a description of what each thread is waiting on, and let the
programmer decide if there is a deadlock.
Hans