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

[Robbin Ehn]

Hi David, looks good.

In the test I would prefer e.g. semaphore acquire/release instead of boolean 
ready with sleep. (in this case it doesn't seem to make much of a difference)
So do as you wish, I do not need to see a new webrev if you choose to change.

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