JDK-8278569 : vmTestbase/nsk/stress/jni/gclocker/gcl001.java times out in loom
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: repo-loom
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2021-12-10
  • Updated: 2022-05-05
  • Resolved: 2022-05-05
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.
Other
repo-loomResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
vmTestbase/nsk/stress/jni/gclocker/gcl001.java timesout,
however process completes after first jcmd invocation.

So no data is collected.
Comments
Every once in a while I want to use SA like hsdb jstack --mixed --pid 3445 but it hangs with no output :(
14-04-2022

Same result as 3/1. Adding a println causes the test to finish, otherwise it hangs. This is running with the vthread wrapper. There are no deadlocks. Nothing is stopping this test. The main thread from jcmd looks like: "main" #1 [3449] prio=5 os_prio=0 cpu=302.28ms elapsed=1292.18s tid=0x0000148a7002a5a0 nid=3449 waiting on condition [0x0000148a7ad2b000] java.lang.Thread.State: WAITING (parking) Thread: 0x0000148a7002a5a0 [0xd79] State: _at_safepoint _at_poll_safepoint 0 JavaThread state: _thread_blocked at jdk.internal.misc.Unsafe.park(java.base@19-internal/Native Method) - parking to wait for <0x0000000730f37830> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(java.base@19-internal/LockSupport.java:221) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@19-internal/AbstractQueuedSynchronizer.java:715) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@19-internal/AbstractQueuedSynchronizer.java:1047) at java.util.concurrent.CountDownLatch.await(java.base@19-internal/CountDownLatch.java:230) at java.lang.VirtualThread.joinNanos(java.base@19-internal/VirtualThread.java:766) at java.lang.Thread.join(java.base@19-internal/Thread.java:2109) at java.lang.Thread.join(java.base@19-internal/Thread.java:2202) at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:88) Test threads look like: "ForkJoinPool-1-worker-12" #813 [3490] daemon prio=5 os_prio=0 cpu=835611.28ms elapsed=1291.69s tid=0x00001489fc0c1fd0 [0x00001489ef3de000] Carrying virtual thread #421 Thread: 0x00001489fc0c1fd0 [0xda2] State: _at_safepoint _at_poll_safepoint 0 JavaThread state: _thread_in_native at jdk.internal.vm.Continuation.run(java.base@19-internal/Continuation.java:260) at java.lang.VirtualThread.runContinuation(java.base@19-internal/VirtualThread.java:213) at java.lang.VirtualThread$$Lambda$7/0x000000080104ae50.run(java.base@19-internal/Unknown Source) at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(java.base@19-internal/ForkJoinTask.java:1421) at java.util.concurrent.ForkJoinTask.doExec(java.base@19-internal/ForkJoinTask.java:385) at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base@19-internal/ForkJoinPool.java:1309) at java.util.concurrent.ForkJoinPool.scan(java.base@19-internal/ForkJoinPool.java:1838) at java.util.concurrent.ForkJoinPool.runWorker(java.base@19-internal/ForkJoinPool.java:1804) at java.util.concurrent.ForkJoinWorkerThread.run(java.base@19-internal/ForkJoinWorkerThread.java:183) (or _thread_blocked because jcmd causes a safepoint). From gdb it looks like these threads are running the test code (calls qsort in native). Can't find the thread that calls Stresser.continueExecution().
14-04-2022

The gcl001.java test has several threads that are turned into virtual threads and have code like: public void run() { if (stresser == null) { stresser = getExecutionController(); } while (stresser.continueExecution()) { // let make at least several values for long/float try { in Stresser.java. the continueExecution() function is here. With the println call, the test completes, otherwise continueExecution() appears to always return true and then times out. No idea. /** * Checks if execution needs to continue. This does not mark new iteration. * * @return true if execution needs to continue */ public boolean continueExecution() { currentTime = System.currentTimeMillis(); if (startTime == 0) { throw new TestBug("Stresser is not started."); } //System.out.println("finishTime " + finishTime + " currentTime " + currentTime); return !forceFinish && !finished && (maxIterations == 0 || iterations < maxIterations) && (finishTime == 0 || currentTime < finishTime); }
01-03-2022