JDK-8231036 : vmTestbase monitoring tests fail after JSR 166 refresh
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-09-16
  • Updated: 2019-10-08
  • Resolved: 2019-09-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14 b17Fixed
Related Reports
Relates :  
JDK-8229442 - AQS and lock classes refresh
Relates :  
JDK-8231032 - ThreadMXBean locking tests fail after JSR 166 refresh
Description
(Split off from JDK-8231032)

After JDK-8229442 many of the vmTestbase tests that use locking are failing because the stacktraces have changed, resulting in unexpected or missing stacktrace elements: 

- vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads*

Checking: nsk.monitoring.share.thread.SynchronizerLockingThreads@6c0bee43 
Unexpected stack trace elements for: nsk.monitoring.share.thread.SynchronizerLockingThreads$Thread2@5b76c522 
   at java.base@14-ea/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3137) 

- vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi* 

Checking: nsk.monitoring.share.thread.SynchronizerLockingThreads@6d4b092f 
Unexpected stack trace elements for: nsk.monitoring.share.thread.SynchronizerLockingThreads$Thread2@766e069 
   at java.base@14-ea/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3137)
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/693c1eb29b8d User: martin Date: 2019-09-27 19:31:11 +0000
27-09-2019
I agree that in retrospect that ManagedBlocker should be an independent interface. But I don't see how this can be done now, given that there are lots of usages out there.
16-09-2019
Ah! Sorry I didn't understand what the error was actually reporting. but I was totally perplexed as to what FJP had to do with this so I printed the whole stack: Unexpected stack trace elements for: nsk.monitoring.share.thread.SynchronizerLockingThreads$Thread2@5ac985a java.base@14-internal/jdk.internal.misc.Unsafe.park(Native Method) java.base@14-internal/java.util.concurrent.locks.LockSupport.park(LockSupport.java:211) java.base@14-internal/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:505) java.base@14-internal/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3137) java.base@14-internal/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1614) app//nsk.monitoring.share.thread.SynchronizerLockingThreads$Thread2.runInside(SynchronizerLockingThreads.java:213) so now I see. Can't say I'm happy. This didn't register with me when we were looking at the managed blocker updates. It looks really bizarre for AQS.ConditionObject to call out to a FJP method when nobody is using FJP at all! That dependency should not be there IMHO. I should be able to run AQS without FJP even being present. I'm guessing this may be connected to Loom? But still unhappy. Edit: ManagedBlocker should be a higher-level API for use by the j.u.c synchronizers, or user-defined ones. If this is really now a low-level API - as the connection to AQS suggests - then perhaps it doesn't really belong in FJP any more.
16-09-2019
> But I don't understand the proposed fix. What types from j.u.c are being found that were previously not? It's there in the description: at java.base@14-ea/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3137)
16-09-2019
The test have been excluded so dropping back to P3. Note the test/hotspot/jtreg/ProblemList.txt will need to be updated as part of this patch.
16-09-2019
RFR should be on serviceability-dev. But I don't understand the proposed fix. What types from j.u.c are being found that were previously not?
16-09-2019
Not sure which mailing list to send RFR... David, you can consider this bug a RFR for the fix for these unloved nsk tests.
16-09-2019
Typical brittle implementation checks of stack frames. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SynchronizerLockingThreads.java b/test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SynchronizerLockingThreads.java --- a/test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SynchronizerLockingThreads.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/SynchronizerLockingThreads.java @@ -243,7 +243,7 @@ protected boolean isStackTraceElementExpected(StackTraceElement element) { return super.isStackTraceElementExpected(element) || checkStackTraceElement(element, expectedMethodsThread2) || - element.getClassName().startsWith("java.util.concurrent.locks.") || + element.getClassName().startsWith("java.util.concurrent.") || element.getClassName().startsWith("jdk.internal.misc."); } }
16-09-2019