RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead of 'waiting to lock'

[David Holmes]

On 23/05/2014 11:56 PM, Daniel D. Daugherty wrote:
> Thanks for the quick review!
>
>
> On 5/23/14 1:39 AM, David Holmes wrote:
>> Hi Dan,
>>
>> Functional changes look good.
>
> Thanks.
>
>
>> For the test I thought the preferred approach these days was to use
>> the testlibrary utilities to launch the test in another VM and also
>> launch the tool. That way the test isn't restricted to needs_jdk.
>
> Don't really know the right answer here. I usually write tests
> like this as a Java program with a shell script wrapper, but I
> know we're trying not to do that anymore.
>
> When I grep'ed for jstack in the hotspot tests, I ran across one:
>
> $ rgrep jstack test
> test/runtime/7194254/Test7194254.java: *      whether jstack reports
> correct priorities for them.
> test/runtime/7194254/Test7194254.java:            String jstack =
> System.getProperty("java.home") + "/../bin/jstack";
> test/runtime/7194254/Test7194254.java:            Process process = new
> ProcessBuilder(jstack, pid)
>
> It turns out that your test for 7194254 was pretty much perfect
> for me to adapt for what I was trying to test. For now, I'm
> inclined to go with the current test if you're OK with that.

That was then, this is now :) testlibrary gives you everything you need 
without having to resort to java.home hacks. And the added benefit is 
that the test is not restricted to being a JDK-only test.

Your call - you are the one that has to do the work.

Cheers,
David


> Dan
>
>
>>
>> Cheers,
>> David
>>
>> On 23/05/2014 2:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack trace
>>>> dump reporting incorrect lock state. The solution is to check the
>>>> monitor's owner, if the owner is other than the current thread, then
>>>> the monitor, is or is in process of being, set the pending monitor of
>>>> current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>