RFR: 8196361: JTReg failure in serviceability/sa/ClhsdbInspect.java
David Holmes
david.holmes at oracle.com
Mon Jan 29 22:05:44 UTC 2018
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