This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: GCJ Thread Dump
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "Bryce McKinlay" <mckinlay at redhat dot com>,"Andrew Haley" <aph at redhat dot com>
- Cc: "Mark Anderson" <mark at panonet dot net>, <java at gcc dot gnu dot org>
- Date: Wed, 9 Feb 2005 14:55:49 -0800
- Subject: RE: GCJ Thread Dump
I'm not sure the locks are that hard either. Assuming hash
synchronization is enabled, I think it's mostly a
matter of walking the lock table. But I haven't thought
about it in detail.
Hans
> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org]
> On Behalf Of Bryce McKinlay
> Sent: Wednesday, February 09, 2005 2:02 PM
> To: Andrew Haley
> Cc: Mark Anderson; java@gcc.gnu.org
> Subject: Re: GCJ Thread Dump
>
>
> Andrew Haley wrote:
>
> >Mark Anderson writes:
> > > Is there any way to get a thread dump from a running GCJ
> application
> > > in the
> > > same way you can send a kill -3 signal to the Sun JVM?
> >
> >No, there isn't, and it would be extremely hard to do. Whan
> we have a
> >problem like this, we attach gdb to the process.
> >
> I'm curious - why is this so difficult? I think Sun's implementation
> shows what locks are held by each thread, along with the stack trace,
> which might be tricky. However, I don't see why plain old
> thread dumps
> would be so hard given that we can already unwind through signal
> handlers. Note that there is a enhancement request for this:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15686
>
> Regards
>
> Bryce
>
>