review request for CR 6361589
Yumin Qi
Yumin.Qi at Sun.COM
Thu Dec 10 16:45:08 PST 2009
Thanks for you all the good suggestions:
1) update the hierarchy comments --- we miss some there
2) Use c'tor-d'tor idiom for remembering JavaThread in GC thread
3) Add one more STEP (135)
4) update vmStructs so the SA can check this value.
Thanks
Yumin
David Holmes - Sun Microsystems wrote:
> Hi Yumin,
>
> Can you update the thread hierarchy comments in thread.hpp:
>
> 49 // Class hierarchy
> 50 // - Thread
> 51 // - VMThread
> 52 // - JavaThread
> 53 // - WatcherThread
>
> This seems incomplete anyway so it would be good to update it.
>
> I would also find it useful to add more comments to the NamedThread
> class explaining the role of this new field. It really has nothing to
> do with being a "named thread" - but then NamedThread should really
> have been called something more general. Pity we can't rename it - can
> we? :)
>
> In vmError.cpp:
>
> 506 // printing Java thread stack trace if it is involved in GC
> crash
> 507
> 508 if (_verbose && (_thread->is_Named_thread())) {
>
> Can/Should this be a new STEP?
>
> David
>
> Yumin Qi said the following on 12/11/09 08:50:
>> Tom,
>>
>> Thanks, changed as pointed.
>> Sorry I forget to include GC group.
>>
>> Can someone else give a look?
>>
>> http://cr.openjdk.java.net/~minqi/6361589
>>
>>
>>
>> Thanks
>> Yumin
>>
>> Tom Rodriguez wrote:
>>> Overall this looks pretty nice.
>>>
>>> java_thread_gc isn't a very clear name. Maybe collected_thread or
>>> processed_thread? The comment should describe it's purpose more
>>> explicitly.
>>>
>>> Is this assert really needed?
>>>
>>> + assert(thread != this, "Should not be java thread itself");
>>>
>>> I think you should add is_NamedThread() instead of distinguishing
>>> all these cases individually.
>>>
>>> If VMThread is now a NamedTread why don't you call set_name instead
>>> of having it override name again?
>>>
>>> vmError.cpp:
>>>
>>> I think the printing output should look more like this:
>>>
>>> + st->print_cr("JavaThread " PTR_FORMAT " was being
>>> processed during the crash, id = " UINTX_FORMAT, jt,
>>> jt->osthread()->thread_id());
>>>
>>> tom
>>>
>>> On Dec 9, 2009, at 2:49 PM, Yumin Qi wrote:
>>>
>>>
>>>> Fixed 6361589: Print out stack trace for target thread of GC crash
>>>>
>>>> http://cr.openjdk.java.net/~minqi/6361589
>>>>
>>>> Comments: This is a facility to assist for JVM crash analysis. To
>>>> implement this function, it needs record JavaThread which may
>>>> involve crash somewhere in GC thread. The place chosen here is
>>>> NamedThread from which all GC threads but VMThread derive. I change
>>>> VMThread's base from Thread to NamedThread, so the recording of
>>>> JavaThread covers for GC threads and VMThread. Once the JavaThread
>>>> recorded in GC thread seen during error report, its stack trace be
>>>> printed out. To test this function, add a debug flag
>>>> CrashGCForDumpingJavaThread, once it is set, it will crash
>>>> immediately in VMThread or GC Thread to core dump. Note this is for
>>>> test only purpose, no defects in involved JavaThread.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>
>>>
>>
More information about the hotspot-runtime-dev
mailing list