This is the mail archive of the
java-patches@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: "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-patches at gcc dot gnu dot org>
- Date: Wed, 24 Sep 2003 20:52:38 +0100
- Subject: RE: deadlock detection
- References: <75A9FEBA25015040A761C1F74975667D014422EB@hplex4.hpl.hp.com><16217.43918.445515.352009@cuddles.cambridge.redhat.com><1063299668.17321.39.camel@gladish-pc.spinnakernet.com><16224.44307.926654.140643@cuddles.cambridge.redhat.com><1064432577.7596.15.camel@gladish-pc.spinnakernet.com>
Jacob Gladish writes:
> I've been trolling through the entire gcc code, and can't seem to find
> generic containers anywhere.
Well, there's some in libstdc++, but it was things like
java.util.LinkedList that I was thinking of.
> I also haven't seen anything that refers to what is and what isn't
> suitable to use as far as external libraries or code. So with that
> said, is it ok to use the stl when hacking on the runtime?
No, please don't. Please use Java libraries in libgcj. No libstdc++
dependencies, please.
> I guess for my personal enjoyment it's fine, but I'd like to
> actually contribute a patch at some point.
>
> My current approach would to be instrument the _Jv_MutexLock
> routine in posix-threads.h. Since we can tell from the _Jv_Mutex_t
> structure whether we are going to go into a wait state before
> calling pthread_mutex_lock. At this point, if we know a wait state
> is about to occurr, an edge would be added to the wait-for-graph
> And then removed once the call returns.
This seems reasonable, but it would restrict all this stuff to
POSIX-only platforms. That suits me well enough, but others might
disagree... ;-)
Andrew.