Re: GCJ Thread Dump

[Bryce McKinlay <mckinlay at redhat dot com>]

Sun's implementation actually shows you where on the stack each lock was 
acquired. Here's an example:

"Java2D Disposer" daemon prio=1 tid=0x08388478 nid=0x3c6d in 
Object.wait() [0xa8247000..0xa82480c0]
       at java.lang.Object.wait(Native Method)
       - waiting on <0xa91d8810> (a java.lang.ref.ReferenceQueue$Lock)
       at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
       - locked <0xa91d8810> (a java.lang.ref.ReferenceQueue$Lock)
       at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
       at sun.java2d.Disposer.run(Disposer.java:107)
       at java.lang.Thread.run(Thread.java:595)

This level of detail would certainly be hard in GCJ, but having it 
iterate through the lock table and just show a list of locks held (and 
being waited on) alongside each thread stack would be almost as useful, 
I think.

Regards

Bryce

Boehm, Hans wrote:

> 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
> >
> >
> >