GCJ Thread Dump

[Bryce McKinlay]

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