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

[Daniel D. Daugherty]

David,

Finally getting back to this thread. New webrev will be out shortly.

Thanks for the careful review of the test. Buried in the refactoring
of the test, I used the testlibrary code to find jstack. I looked at
other parts of the testlibrary code, but I don't think they'll work
for what I'm trying to do here. I've added comments to the test to
explain my rationale.

I'm sticking with using the 'test JDK' version of jstack since that
program is often closely coupled with the VM itself. This means that
the test is still flagged as 'jdk only'. I understand that in the
embedded world, the 'test JRE' is a subset of 'compile JDK', but we
don't know if that's true in all non-embedded cases.

Dan


On 5/23/14 6:04 PM, David Holmes wrote:
> 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
>>>>>
>>>>
>>