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@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
