jdk19 MiniMix_aot_5m_0 hang #15917

pshipton · 2022-09-19T14:37:17Z

https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/8
MiniMix_aot_5m_0

There is a javacore and core created after the hang, but also another core.1202972 which isn't renamed. Likely caused by sending signals since it's created a minute after the renamed core file.

https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/8/system_test_output.tar.gz

LT  06:01:05.015 - Completed 20.0%. Number of tests started=10571 (+4241)
STF 06:05:03.037 - Heartbeat: Process LT  is still running
STF 06:10:03.284 - Heartbeat: Process LT  is still running
STF 06:15:03.166 - Heartbeat: Process LT  is still running
STF 06:20:03.478 - Heartbeat: Process LT  is still running
STF 06:25:03.249 - Heartbeat: Process LT  is still running
STF 06:30:03.295 - Heartbeat: Process LT  is still running
STF 06:35:03.021 - Heartbeat: Process LT  is still running
STF 06:40:03.236 - Heartbeat: Process LT  is still running
STF 06:45:03.344 - Heartbeat: Process LT  is still running
STF 06:50:03.261 - Heartbeat: Process LT  is still running
STF 06:55:03.194 - Heartbeat: Process LT  is still running
STF 07:00:03.453 - Heartbeat: Process LT  is still running
STF 07:05:03.250 - Heartbeat: Process LT  is still running
STF 07:05:04.253 - **FAILED** Process LT  has timed out
STF 07:05:04.254 - Collecting dumps for: LT 
STF 07:05:04.254 - Sending SIG 3 to the java process to generate a javacore
STF 07:05:04.255 - Running command: kill -3 1202972
STF 07:05:04.255 - Redirecting stderr to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stderr
STF 07:05:04.255 - Redirecting stdout to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stdout
STF 07:05:04.256 - Pausing for 30 seconds
STF 07:05:34.259 - Sending SIG 3 to the java process to generate a javacore
STF 07:05:34.259 - Running command: kill -3 1202972
STF 07:05:34.259 - Redirecting stderr to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stderr
STF 07:05:34.259 - Redirecting stdout to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stdout
STF 07:05:34.260 - Pausing for 30 seconds
STF 07:06:04.262 - Sending SIG 3 to the java process to generate a javacore
STF 07:06:04.310 - Running command: kill -3 1202972
STF 07:06:04.310 - Redirecting stderr to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stderr
STF 07:06:04.310 - Redirecting stdout to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_3.stdout
STF 07:06:04.311 - Pausing for 30 seconds
STF 07:06:34.311 - Sending SIGABRT (kill -6) to the java process to generate a core
STF 07:06:34.312 - Running command: kill -6 1202972
STF 07:06:34.312 - Redirecting stderr to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_6.stderr
STF 07:06:34.312 - Redirecting stdout to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_6.stdout
STF 07:06:34.313 - Pausing for 30 seconds
STF 07:07:04.315 - Sending SIGXCPU (kill -24) to the java process to generate an OS dump
STF 07:07:04.315 - Running command: kill -24 1202972
STF 07:07:04.315 - Redirecting stderr to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_24.stderr
STF 07:07:04.315 - Redirecting stdout to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/1.LT.kill_24.stdout
LT  stderr JVMDUMP039I Processing dump event "user", detail "" at 2022/09/17 07:05:04 - please wait.
LT  stderr JVMDUMP032I JVM requested System dump using '/home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/core.20220917.070504.1202972.0001.dmp' in response to an event
LT  stderr JVMDUMP010I System dump written to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/core.20220917.070504.1202972.0001.dmp
LT  stderr JVMDUMP032I JVM requested Java dump using '/home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/javacore.20220917.070504.1202972.0002.txt' in response to an event
LT  stderr JVMDUMP010I Java dump written to /home/jenkins/workspace/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_1/aqa-tests/TKG/output_1663392324450/MiniMix_aot_5m_0/20220917-060001-MixedLoadTest/results/javacore.20220917.070504.1202972.0002.txt
LT  stderr JVMDUMP013I Processed dump event "user", detail "".

The text was updated successfully, but these errors were encountered:

pshipton · 2022-10-19T17:45:34Z

https://openj9-jenkins.osuosl.org/job/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_2/30
MiniMix_aot_5m_0

https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk19_j9_extended.system_s390x_linux_Nightly_testList_2/30/system_test_output.tar.gz

I see this:

2LKMONINUSE      sys_mon_t:0x000003FF8C183F68 infl_mon_t: 0x000003FF8C183FE8:
3LKMONOBJECT       java/lang/Thread@0x000000007CFF0260: <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-1" (J9VMThread:0x0000000000678A00)

2LKREGMON          VM thread list lock (0x000003FF8C01D428): Flat locked by "load-8" (J9VMThread:0x0000000000689300), entry count 1
3LKWAITERQ            Waiting to enter:
3LKWAITER                "JIT-SamplerThread" (J9VMThread:0x0000000000100C00)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C185DA8): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-8" (J9VMThread:0x0000000000689300)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C27DBF8): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-4" (J9VMThread:0x000000000067FB00)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C2BF528): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-3" (J9VMThread:0x000000000067D600)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C2C0918): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-2" (J9VMThread:0x000000000067B000)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C2C0BD8): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-6" (J9VMThread:0x0000000000684700)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C2C9108): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-5" (J9VMThread:0x0000000000682100)

2LKREGMON          Thread public flags mutex lock (0x000003FF8C2C9528): <unowned>
3LKNOTIFYQ            Waiting to be notified:
3LKWAITNOTIFY            "load-9" (J9VMThread:0x000000000068B900)

3XMTHREADINFO      "load-8" J9VMThread:0x0000000000689300, omrthread_t:0x000003FF8C62A030, java/lang/Thread:0x000000000CCA3C18, state:R, prio=5
3XMJAVALTHREAD            (java/lang/Thread getId:0x1F, isDaemon:false)
3XMJAVALTHRCCL            jdk/internal/loader/ClassLoaders$AppClassLoader(0x000000000CC2CB88)
3XMTHREADINFO1            (native thread ID:0x2F25D0, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00049000)
3XMTHREADINFO2            (native stack address range from:0x000003FF90140000, to:0x000003FF90180000, size:0x40000)
3XMCPUTIME               CPU usage total: 33.563451488 secs, current category="Application"
3XMHEAPALLOC             Heap bytes allocated since last GC cycle=55368368 (0x34CDAB0)
3XMTHREADINFO3           Java callstack:
4XESTACKTRACE                at java/lang/Thread.getThreads(Native Method)
4XESTACKTRACE                at java/lang/Thread.getAllThreads(Thread.java:2701(Compiled Code))
4XESTACKTRACE                at java/lang/ThreadGroup.activeCount(ThreadGroup.java:377)
4XESTACKTRACE                at gnu/testlet/java/lang/ThreadGroup/enumerate.test(enumerate.java:46)

pshipton · 2022-10-19T17:46:52Z

@tajila fyi

tajila · 2022-10-19T18:49:12Z

Based on the native stack trace, the thread is blocked in GC code

4XENATIVESTACK                (0x000003FF9017D6C8 [<unknown>+0x0])
4XENATIVESTACK               pthread_cond_wait+0x226 (0x000003FF9250E81E [libpthread.so.0+0xe81e])
4XENATIVESTACK                (0x000003FF91987B26 [libj9thr29.so+0x7b26])
4XENATIVESTACK               omrthread_monitor_wait+0x60 (0x000003FF9198B690 [libj9thr29.so+0xb690])
4XENATIVESTACK                (0x000003FF91B98D9A [libj9vm29.so+0x98d9a])
4XENATIVESTACK                (0x000003FF91B98B78 [libj9vm29.so+0x98b78])
4XENATIVESTACK                (0x000003FF90951F82 [libj9gc29.so+0x51f82])
4XENATIVESTACK               Java_java_lang_Thread_getThreads+0x12e (0x000003FF905D760E [libjclse29.so+0x5760e])
4XENATIVESTACK                (0x000003FF70AE0E84 [<unknown>+0x0])

tajila · 2022-10-19T18:51:23Z

The GC call is probably J9AllocateIndexableObject

tajila · 2022-10-19T19:00:09Z

@ChengJin01 can you look at this issue, I think its related to #16036 (comment)

ChengJin01 · 2022-10-19T23:24:45Z

The native stacktrace of thread load-8 shows it was blocked in internalAcquireVMAccess of J9AllocateIndexableObject by checking these .so files via objdump:

3XMTHREADINFO      "load-8" J9VMThread:0x0000000000689300, omrthread_t:0x000003FF8C62A030, java/lang/Thread:0x000000000CCA3C18, state:R, prio=5
3XMJAVALTHREAD            (java/lang/Thread getId:0x1F, isDaemon:false)
3XMJAVALTHRCCL            jdk/internal/loader/ClassLoaders$AppClassLoader(0x000000000CC2CB88)
3XMTHREADINFO1            (native thread ID:0x2F25D0, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00049000)
3XMTHREADINFO2            (native stack address range from:0x000003FF90140000, to:0x000003FF90180000, size:0x40000)
3XMCPUTIME               CPU usage total: 33.563578303 secs, current category="Application"
3XMHEAPALLOC             Heap bytes allocated since last GC cycle=55368368 (0x34CDAB0)
3XMTHREADINFO3           Java callstack:
4XESTACKTRACE                at java/lang/Thread.getThreads(Native Method)
4XESTACKTRACE                at java/lang/Thread.getAllThreads(Thread.java:2701(Compiled Code))
4XESTACKTRACE                at java/lang/ThreadGroup.activeCount(ThreadGroup.java:377)
4XESTACKTRACE                at gnu/testlet/java/lang/ThreadGroup/enumerate.test(enumerate.java:46)
4XESTACKTRACE                at java/lang/invoke/LambdaForm$DMH/0x00000000f4006500.invokeVirtual(LambdaForm$DMH(Compiled Code))
4XESTACKTRACE                at java/lang/invoke/LambdaForm$MH/0x00000000f8005c20.invoke(LambdaForm$MH(Compiled Code))
4XESTACKTRACE                at java/lang/invoke/LambdaForm$MH/0x000000008c49fb00.invokeExact_MT(LambdaForm$MH(Compiled Code))
4XESTACKTRACE                at jdk/internal/reflect/DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155(Compiled Code))
4XESTACKTRACE                at jdk/internal/reflect/DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104(Compiled Code))
4XESTACKTRACE                at java/lang/reflect/Method.invoke(Method.java:578(Compiled Code))
4XESTACKTRACE                at net/adoptopenjdk/loadTest/adaptors/MauveAdaptor.executeTest(MauveAdaptor.java:74(Compiled Code))
4XESTACKTRACE                at net/adoptopenjdk/loadTest/LoadTestRunner$2.run(LoadTestRunner.java:182)
4XESTACKTRACE                at java/util/concurrent/ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
4XESTACKTRACE                at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
4XESTACKTRACE                at java/lang/Thread.run(Thread.java:1573)
3XMTHREADINFO3           Native callstack:
4XENATIVESTACK                (0x000003FF91A2DB52 [libj9prt29.so+0x2db52])
4XENATIVESTACK                (0x000003FF91A32BA8 [libj9prt29.so+0x32ba8])
4XENATIVESTACK                (0x000003FF91A2E0C4 [libj9prt29.so+0x2e0c4])
4XENATIVESTACK                (0x000003FF91A32BA8 [libj9prt29.so+0x32ba8])
4XENATIVESTACK                (0x000003FF91A2D9CC [libj9prt29.so+0x2d9cc])
4XENATIVESTACK                (0x000003FF91A2F0DC [libj9prt29.so+0x2f0dc])
4XENATIVESTACK                (0x000003FF9017D6C8 [<unknown>+0x0])
4XENATIVESTACK               pthread_cond_wait+0x226 (0x000003FF9250E81E [libpthread.so.0+0xe81e])
4XENATIVESTACK                (0x000003FF91987B26 [libj9thr29.so+0x7b26])
4XENATIVESTACK               omrthread_monitor_wait+0x60 (0x000003FF9198B690 [libj9thr29.so+0xb690])
4XENATIVESTACK                (0x000003FF91B98D9A [libj9vm29.so+0x98d9a]) <-- internalAcquireVMAccessNoMutexWithMask
4XENATIVESTACK                (0x000003FF91B98B78 [libj9vm29.so+0x98b78]) <-- internalAcquireVMAccess
4XENATIVESTACK                (0x000003FF90951F82 [libj9gc29.so+0x51f82]) <--- J9AllocateIndexableObject
4XENATIVESTACK               Java_java_lang_Thread_getThreads+0x12e (0x000003FF905D760E [libjclse29.so+0x5760e])
4XENATIVESTACK                (0x000003FF70AE0E84 [<unknown>+0x0])

against the output of objdump as follows:

$ objdump -d -DRSC --no-show-raw-insn  --start-address=0x51f82 --stop-address=0x51f8f  ./lib/default/libj9gc29.so
./lib/default/libj9gc29.so:     file format elf64-s390
Disassembly of section .text:
0000000000051f82 <J9AllocateIndexableObject+0xb72>:
   51f82:       ltg     %r1,280(%r15)
   51f88:       je      51f9c <J9AllocateIndexableObject+0xb8c>
   51f8c:       lg      %r2,184(%r15)

$ objdump -d -DRSC --no-show-raw-insn  --start-address=0x98b78 --stop-address=0x98b7f  ./lib/default/libj9vm29.so
./lib/default/libj9vm29.so:     file format elf64-s390
Disassembly of section .text:
0000000000098b78 <internalAcquireVMAccess+0x78>:
   98b78:       lgr     %r3,%r9
   98b7c:       lgr     %r2,%r10

$ objdump -d -DRSC --no-show-raw-insn  --start-address=0x98d9a --stop-address=0x98d9f  ./lib/default/libj9vm29.so
./lib/default/libj9vm29.so:     file format elf64-s390
Disassembly of section .text:
0000000000098d9a <internalAcquireVMAccessNoMutexWithMask+0x8a>:
   98d9a:       lg      %r1,152(%r10)

Looking at the code in Java_java_lang_Thread_getThreads at

openj9/runtime/jcl/common/thread.cpp

Line 527 in aea459a

    
           j9object_t arrayObject = vm->memoryManagerFunctions->J9AllocateIndexableObject(currentThread, arrayClass, (U_32)threadCount, J9_GC_ALLOCATE_OBJECT_NON_INSTRUMENTABLE);

and the code in J9AllocateIndexableObject at

openj9/runtime/gc_modron_startup/mgcalloc.cpp

Line 692 in e674448

vmThread->javaVM->internalVMFunctions->internalAcquireVMAccess(vmThread);

, which belongs to GC and was newly added via Fix halted thread being allowed to continue execution v2 #15227 or Fix halted thread being allowed to continue execution #15201 (related to the thread inspection in VM).

FYI: @amicic, @gacholio

tajila · 2022-10-21T15:12:03Z

@gacholio do we need a J9_ARE_ANY_BITS_SET(vm->extendedRuntimeFlags, J9_EXTENDED_RUNTIME_OSR_SAFE_POINT); check in getThreads? We had a similar problem with the CRIU code when a GC was trigger under exclusive

gacholio · 2022-10-21T15:25:46Z

I'll have a look, but I don't think so. Exclusive and safepoint are supposed to co-exist. I have the core but I haven't decoded all the flags yet.

JasonFengJ9 · 2022-10-24T15:35:26Z

This issue (on zlinux) wasn't seen on internal builds.
Launched 50x internal grinder

gacholio · 2022-10-24T15:47:18Z

I've just taken a look at the implementation of getThreads and it's allocating objects and throwing exceptions while holding exclusive which is absolutely illegal. The native needs to be rewritten and we should do a scan for other similar offenders.

openj9/runtime/jcl/common/thread.cpp

Lines 485 to 545 in bb7dc4e

    
           /* private static native Thread[] getThreads(); */ 
        
           jobjectArray JNICALL 
        
           Java_java_lang_Thread_getThreads(JNIEnv *env, jclass clazz) 
        
           { 
        
           	J9VMThread *currentThread = (J9VMThread*)env; 
        
           	J9JavaVM *vm = currentThread->javaVM; 
        
           	J9InternalVMFunctions *vmFuncs = vm->internalVMFunctions; 
        
           	jobjectArray result = NULL; 
        
           	PORT_ACCESS_FROM_JAVAVM(vm); 
        
           	vmFuncs->internalEnterVMFromJNI(currentThread); 
        
           	vmFuncs->acquireExclusiveVMAccess(currentThread); 
        
           	jobject *threads = (jobject*)j9mem_allocate_memory(sizeof(jobject) * vm->totalThreadCount, J9MEM_CATEGORY_VM_JCL); 
        
           	if (NULL == threads) { 
        
           		vmFuncs->setNativeOutOfMemoryError(currentThread, 0, 0); 
        
           	} else { 
        
           		jobject *currentThreadPtr = threads; 
        
           		J9VMThread *targetThread = vm->mainThread; 
        
           		UDATA threadCount = 0; 
        
           		do { 
        
           #if JAVA_SPEC_VERSION >= 19 
        
           			/* carrierThreadObject should always point to a platform thread. 
        
           			 * Thus, all virtual threads should be excluded. 
        
           			 */ 
        
           			j9object_t threadObject = targetThread->carrierThreadObject; 
        
           #else /* JAVA_SPEC_VERSION >= 19 */ 
        
           			j9object_t threadObject = targetThread->threadObject; 
        
           #endif /* JAVA_SPEC_VERSION >= 19 */ 
        
           			/* Only count live threads */ 
        
           			if (NULL != threadObject) { 
        
           				if (J9VMJAVALANGTHREAD_STARTED(currentThread, threadObject) && (NULL != J9VMJAVALANGTHREAD_THREADREF(currentThread, threadObject))) { 
        
           					*currentThreadPtr++ = vmFuncs->j9jni_createLocalRef(env, threadObject);; 
        
           					threadCount += 1; 
        
           				} 
        
           			} 
        
           			targetThread = targetThread->linkNext; 
        
           		} while (targetThread != vm->mainThread); 
        
           		J9Class *arrayClass = fetchArrayClass(currentThread, J9VMJAVALANGTHREAD_OR_NULL(vm)); 
        
           		if (NULL != arrayClass) { 
        
           			j9object_t arrayObject = vm->memoryManagerFunctions->J9AllocateIndexableObject(currentThread, arrayClass, (U_32)threadCount, J9_GC_ALLOCATE_OBJECT_NON_INSTRUMENTABLE); 
        
           			if (NULL != arrayObject) { 
        
           				for (UDATA i = 0; i < threadCount; i++) { 
        
           					J9JAVAARRAYOFOBJECT_STORE(currentThread, arrayObject, i, J9_JNI_UNWRAP_REFERENCE(threads[i])); 
        
           				} 
        
           				result = (jobjectArray)vmFuncs->j9jni_createLocalRef(env, arrayObject); 
        
           			} else { 
        
           				vmFuncs->setHeapOutOfMemoryError(currentThread); 
        
           			} 
        
           		} 
        
           		j9mem_free_memory(threads); 
        
           	} 
        
           	vmFuncs->releaseExclusiveVMAccess(currentThread); 
        
           	vmFuncs->internalExitVMToJNI(currentThread); 
        
           	return result; 
        
           }

gacholio · 2022-10-24T16:04:41Z

It's quite possible that #15227 exposed the problems with this native, but the things it's doing have always been invalid.

gacholio · 2022-10-24T16:34:45Z

The code is already creating refs for the Thread objects, so fixing this may be as simple as moving the releaseExclusiveVMAccess to after the first loop (and fixing any exceptions being thrown under exclusive).

Fixes: eclipse-openj9#15917 Signed-off-by: Graham Chapman <[email protected]>

pshipton added the test failure label Sep 19, 2022

pshipton added this to the Java 19 milestone Sep 19, 2022

pshipton added the jdk19 label Sep 19, 2022

tajila added the comp:vm label Oct 21, 2022

eclipse-openj9 deleted a comment from tajila Oct 24, 2022

gacholio mentioned this issue Oct 24, 2022

Use exclusive access correctly in getThreads #16180

Merged

gacholio added a commit to gacholio/openj9 that referenced this issue Oct 24, 2022

Use exclusive access correctly in getThreads

2d9d709

Fixes: eclipse-openj9#15917 Signed-off-by: Graham Chapman <[email protected]>

tajila closed this as completed in #16180 Oct 24, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

jdk19 MiniMix_aot_5m_0 hang #15917

jdk19 MiniMix_aot_5m_0 hang #15917

pshipton commented Sep 19, 2022 •

edited

Loading

pshipton commented Oct 19, 2022 •

edited

Loading

pshipton commented Oct 19, 2022

tajila commented Oct 19, 2022

tajila commented Oct 19, 2022

tajila commented Oct 19, 2022

ChengJin01 commented Oct 19, 2022 •

edited

Loading

tajila commented Oct 21, 2022

gacholio commented Oct 21, 2022

JasonFengJ9 commented Oct 24, 2022

gacholio commented Oct 24, 2022

gacholio commented Oct 24, 2022

gacholio commented Oct 24, 2022

jdk19 MiniMix_aot_5m_0 hang #15917

jdk19 MiniMix_aot_5m_0 hang #15917

Comments

pshipton commented Sep 19, 2022 • edited Loading

pshipton commented Oct 19, 2022 • edited Loading

pshipton commented Oct 19, 2022

tajila commented Oct 19, 2022

tajila commented Oct 19, 2022

tajila commented Oct 19, 2022

ChengJin01 commented Oct 19, 2022 • edited Loading

tajila commented Oct 21, 2022

gacholio commented Oct 21, 2022

JasonFengJ9 commented Oct 24, 2022

gacholio commented Oct 24, 2022

gacholio commented Oct 24, 2022

gacholio commented Oct 24, 2022

pshipton commented Sep 19, 2022 •

edited

Loading

pshipton commented Oct 19, 2022 •

edited

Loading

ChengJin01 commented Oct 19, 2022 •

edited

Loading