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

[Robbin Ehn]

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