RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java

[David Holmes]

On 30/01/2018 9:57 PM, Jini George wrote:
> Hi Daniel, David,
> 
> Thanks, Daniel, for bringing this up. The intent of the test is to get 
> the oop address corresponding to a java.lang.ref.ReferenceQueue$Lock, 
> which can typically be obtained from the stack traces of the 
> Common-Cleaner or the Finalizer threads. The stack traces which I had 
> been noticing were typically of the form:
> 
> 
> "Common-Cleaner" #8 daemon prio=8 tid=0x00007f09c82ac000 nid=0xf6e in 
> Object.wait() [0x00007f09a18d2000]
>     java.lang.Thread.State: TIMED_WAITING (on object monitor)
>     JavaThread state: _thread_blocked
>   - java.lang.Object.wait(long) @bci=0, pc=0x00007f09b7d6480b, 
> Method*=0x00007f09acc43d60 (Interpreted frame)
>          - waiting on <0x000000072e61f6e0> (a 
> java.lang.ref.ReferenceQueue$Lock)
>   - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=151, 
> pc=0x00007f09b7d55243, Method*=0x00007f09acdab9b0 (Interpreted frame)
>          - waiting to re-lock in wait() <0x000000072e61f6e0> (a 
> java.lang.ref.ReferenceQueue$Lock)
> ...
> 
> I chose 'waiting to re-lock in wait' since that was what I had been 
> observing next to the oop address of java.lang.ref.ReferenceQueue$Lock. 

Actually that output is itself a bug:

https://bugs.openjdk.java.net/browse/JDK-8150689

David
-----

> But I see how with a timing difference, one could get 'waiting to lock' 
> as in your case. So, a good way to fix might be to check for the line 
> containing '(a java.lang.ref.ReferenceQueue$Lock)', getting the oop 
> address from that line (should be the address appearing immediately 
> before '(a java.lang.ref.ReferenceQueue$Lock)') and passing that to the 
> 'inspect' command.
> 
> Thanks much,
> Jini.
> 
> On 1/30/2018 3:35 AM, David Holmes wrote:
>> Hi Daniel,
>>
>> Serviceability issues should go to serviceability-dev at openjdk.java.net 
>> - now cc'd.
>>
>> On 30/01/2018 7:53 AM, stewartd.qdt wrote:
>>> Please review this webrev [1] which attempts to fix a test error in 
>>> serviceability/sa/ClhsdbInspect.java when it is run under an AArch64 
>>> system (not necessarily exclusive to this system, but it was the 
>>> system under test). The bug report [2] provides further details. 
>>> Essentially the line "waiting to re-lock in wait" never actually 
>>> occurs. Instead I have the line "waiting to lock" which occurs for 
>>> the referenced item of /java/lang/ref/ReferenceQueue$Lock. 
>>> Unfortunately the test is written such that only the first "waiting 
>>> to lock" occurrence is seen (for java/lang/Class), which is already 
>>> accounted for in the test.
>>
>> I can't tell exactly what the test expects, or why, but it would be 
>> extremely hard to arrange for "waiting to re-lock in wait" to be seen 
>> for the ReferenceQueue lock! That requires acquiring the lock 
>> yourself, issuing a notify() to unblock the wait(), and then issuing 
>> the jstack command while still holding the lock!
>>
>> David
>> -----
>>
>>> I'm not overly happy with this approach as it actually removes a test 
>>> line. However, the test line does not actually appear in the output 
>>> (at least on my system) and the test is not currently written to look 
>>> for the second occurrence of the line "waiting to lock". Perhaps the 
>>> original author could chime in and provide further guidance as to the 
>>> intention of the test.
>>>
>>> I am happy to modify the patch as necessary.
>>>
>>> Regards,
>>> Daniel Stewart
>>>
>>>
>>> [1] -  http://cr.openjdk.java.net/~dstewart/8196361/webrev.00/
>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8196361
>>>