RFR 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected

[Daniel D. Daugherty]

Adding serviceability-dev at ... since the 'tmtools' including 'jstack'
are owned by the Serviceability team.

Dan


On 11/28/18 4:21 PM, Patricio Chilano wrote:
> Hi all,
>
> Could you review this fix for test 
> serviceability/tmtools/jstack/WaitNotifyThreadTest.java?
>
> On one hand the test was not properly checking what it was intended to 
> check, since as mentioned in JBS the logic for checking the method 
> name was wrong. Also since there was only one monitor in the test, the 
> "for" loop with the message "waiting to re-lock in wait()" was never 
> actually reached.
>
> Additionally, with change 8150689 the message "waiting to re-lock in 
> wait()" is now shown in the frame where the relocking is actually 
> taking place, so the logic for checking that should change.
>
> I fixed the first issues and added logic to check for the "waiting to 
> re-lock in wait()" case. I used the Thread.State attribute to check 
> desire states are reached before getting the thread dump reports 
> through jstack. I run the test in mach5 several times for all 
> platforms and they all passed.
>
> Webrev URL: http://cr.openjdk.java.net/~pchilanomate/8214148.01/webrev
> Bug URL: https://bugs.openjdk.java.net/browse/JDK-8214148 
> <https://bugs.openjdk.java.net/browse/JDK-8150689>
>
> Thanks,
> Patricio