RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java
Jini George
jini.george at oracle.com
Tue Jan 30 11:57:36 UTC 2018
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.
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
>>
More information about the serviceability-dev
mailing list