review request for CR 6361589
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Thu Dec 10 20:16:31 PST 2009
Looks good to me Yumin.
Thanks,
David
Yumin Qi said the following on 12/11/09 14:10:
> Thanks.
>
> I modified the code and submitted again. Please take a look again, will
> commit if it is OK.
>
> Thanks
> Yumin
>
> Coleen Phillimore wrote:
>>
>> Yumin,
>> I've already reviewed a previous version and this still looks great to
>> me. I hope this makes diagnosing crashes during gc much better,
>> rather than having to decode the thread manually as you've been doing
>> for years.
>> Thanks everyone for the additional comments. The later suggested
>> changes are really good.
>>
>> Coleen
>>
>> Yumin Qi wrote:
>>> 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