GCJ Thread Dump

Thu Feb 10 14:34:00 GMT 2005

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