RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor

[David Holmes]

Thanks again Robbin.

David

On 15/01/2019 6:13 pm, Robbin Ehn wrote:
>>
>> http://cr.openjdk.java.net/~dholmes/8213397/webrev.v2
> 
> Ship it!
> 
> /Robbin
> 
>>
>> This also addresses Coleen's suggestion to remove the assert in the 
>> vframe code.
>>
>> Thanks,
>> David
>> -----
>>
>>
>>> Thanks,
>>> David
>>>
>>>> Thanks, Robbin
>>>>
>>>> On 1/14/19 7:01 AM, David Holmes wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/
>>>>>
>>>>> Please review this simple enhancement to improve the stack trace 
>>>>> information when a thread is blocked doing a (logical) Object.wait 
>>>>> on the monitor associated with Class static initialization.
>>>>>
>>>>> Details are in the bug report but basically we record, in a 
>>>>> thread-local variable, the name of the class before the "wait" and 
>>>>> clear it after, thus allowing the stack dump code to query it if it 
>>>>> appears we may be in that situation.
>>>>>
>>>>> In InstanceKlass::initialize_impl I also refactored the code a tiny 
>>>>> bit to make use of the JavaThread reference to the current thread.
>>>>>
>>>>> A new test using jstack was also added.
>>>>>
>>>>> Testing:
>>>>>    - mach5 tiers 1 - 3
>>>>>    - the new test on Windows/Linux/OSX x86 and Solaris sparc, in 
>>>>> regular and Xcomp mode
>>>>>    - All jstack/stack-dump using tests I could see (linux x64):
>>>>>      - runtime/Thread
>>>>>      - serviceability/sa/
>>>>>      - serviceability/tmtools/jstack/
>>>>>      - vmTestbase/nsk/jvmti/scenarios/sampling/
>>>>>      - vmTestbase/nsk/jvmti/MonitorWaited/ .
>>>>>      - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/
>>>>>
>>>>> Thanks,
>>>>> David