Update j9jni_deleteGlobalRef assertion check to allow exclusive access by JasonFengJ9 · Pull Request #23595 · eclipse-openj9/openj9

JasonFengJ9 · 2026-03-27T15:32:52Z

Update j9jni_deleteGlobalRef assertion check to allow exclusive access

Ensure j9jni_deleteGlobalRef() caller has exclusive or VM access.

closes #23570

Signed-off-by: Jason Feng fengj@ca.ibm.com

gacholio · 2026-03-27T15:37:47Z

Please read the comments in the issue again - I believe my suggestion is incorrect, and there's an ifdef to remove.

JasonFengJ9 · 2026-03-27T15:48:30Z

and there's an ifdef to remove.

If you meant following ifdef, it is removed.

openj9/runtime/vm/jnicsup.cpp

Lines 1699 to 1701 in 14edc02

    
           #if defined(J9VM_GC_REALTIME) 
        
           		vm->memoryManagerFunctions->j9gc_objaccess_jniDeleteGlobalReference(vmThread, *((j9object_t*)globalRef)); 
        
           #endif /* defined(J9VM_GC_REALTIME) */

JasonFengJ9 · 2026-03-27T15:53:12Z

A better solution is to check (0 != vmThread->exclusiveCount) || (0 != vmThread->safePointCount).
Actually this may not work with Metronome where the exclusive holder is not the current thread.

Yes, exclusiveAccessResponseCount is set to 0 for Metronome.
0x18d8: UDATA exclusiveAccessResponseCount = 0x0000000000000000 (0)

	Assert_VM_true(J9_ARE_ANY_BITS_SET(vmThread->publicFlags, J9_PUBLIC_FLAGS_VM_ACCESS)
			|| (0 != vmThread->omrVMThread->exclusiveCount)
			|| (0 != vmThread->safePointCount));

This doesn't tigger an assertion failure for -Xgcpolicy:metronome in the original failing case.

@dmitripivkine does this work for metronome in a different way somehow?

gacholio · 2026-03-27T16:02:32Z

The problem with metronome is that one thread acqiures exclusive and then hands off to another thread to do the work, so the thread doing the class unloading does not have the count set.

dmitripivkine · 2026-03-27T16:03:21Z

A better solution is to check (0 != vmThread->exclusiveCount) || (0 != vmThread->safePointCount).
Actually this may not work with Metronome where the exclusive holder is not the current thread.

Yes, exclusiveAccessResponseCount is set to 0 for Metronome.
0x18d8: UDATA exclusiveAccessResponseCount = 0x0000000000000000 (0)
	Assert_VM_true(J9_ARE_ANY_BITS_SET(vmThread->publicFlags, J9_PUBLIC_FLAGS_VM_ACCESS)
			|| (0 != vmThread->omrVMThread->exclusiveCount)
			|| (0 != vmThread->safePointCount));
This doesn't tigger an assertion failure for -Xgcpolicy:metronome in the original failing case.

@dmitripivkine does this work for metronome in a different way somehow?

In the core vmThread->omrVMThread->exclusiveCount is set to one, there is a way how it is passing

	0x48: U64 exclusiveCount = 0x0000000000000001 (1)

Ensure j9jni_deleteGlobalRef() caller has exclusive or VM access. Signed-off-by: Jason Feng <fengj@ca.ibm.com>

JasonFengJ9 · 2026-03-27T18:37:41Z

The problem with metronome is that one thread acqiures exclusive and then hands off to another thread to do the work, so the thread doing the class unloading does not have the count set.

Changed to check exclusiveAccessState/safePointState in J9JavaVM instead of those within a J9VMThread.

	Assert_VM_true(J9_ARE_ANY_BITS_SET(vmThread->publicFlags, J9_PUBLIC_FLAGS_VM_ACCESS)
			|| (J9_XACCESS_EXCLUSIVE == vm->exclusiveAccessState)
			|| (J9_XACCESS_EXCLUSIVE == vm->safePointState));

JasonFengJ9 · 2026-03-27T18:38:02Z

@gacholio this is ready for another look.

gacholio · 2026-03-27T20:42:30Z

jenkins test functional.extended xlinux jdk25

pshipton · 2026-03-27T21:25:36Z

jenkins test extended.functional xlinux jdk25

gacholio · 2026-03-28T13:33:00Z

jenkins test extended.functional xlinux jdk25

gacholio · 2026-03-29T14:51:14Z

Testing has aborted two tries in a row.

JasonFengJ9 · 2026-03-30T13:03:07Z

threadMXBeanTestSuite1_5 hung. It can be reproduced locally via -Xgcpolicy:metronome with JIT on, passed with -Xint.

Attached gdb to the process and generated a core file. It seems GC has exclusive access without VM access, all other threads were halted but one of them has VM access.

    !j9vmthread 0x7f6498a9a000 publicFlags=41000 privateFlags=1008 inNative=0 // main
    !j9vmthread 0x7f6374003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-000 Suspended
    !j9vmthread 0x7f636c003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-001
    !j9vmthread 0x7f6370003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-002 Suspended
    !j9vmthread 0x7f6364003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-003 Suspended
    !j9vmthread 0x7f6368003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-004 Suspended
    !j9vmthread 0x7f635c003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-005 Suspended
    !j9vmthread 0x7f6360003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Compilation Thread-006 Suspended
    !j9vmthread 0x7f6354003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT Diagnostic Compilation Thread-007 Suspended
    !j9vmthread 0x7f6358003c00 publicFlags=81 privateFlags=101a inNative=0 // JIT-SamplerThread
    !j9vmthread 0x7f633c003c00 publicFlags=81 privateFlags=101a inNative=0 // IProfiler
    !j9vmthread 0x7f6498c77e00 publicFlags=81 privateFlags=2 inNative=0 // Common-Cleaner
    !j9vmthread 0x7f6330003c00 publicFlags=81 privateFlags=80001a inNative=0 // GC Worker
    !j9vmthread 0x7f6328003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f632c003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f6320003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f6324003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f6318003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f631c003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f6310003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Worker
    !j9vmthread 0x7f6314003c00 publicFlags=81 privateFlags=1a inNative=0 // GC Alarm
    !j9vmthread 0x7f6308025800 publicFlags=481 privateFlags=2 inNative=0 // Attach API update file access time
    !j9vmthread 0x7f630802dc00 publicFlags=a1 privateFlags=2 inNative=1 // Attach API wait loop
    !j9vmthread 0x7f6498e19800 publicFlags=81 privateFlags=0 inNative=0 // sleep1
    !j9vmthread 0x7f6499313000 publicFlags=81 privateFlags=0 inNative=0 // sleep2
    !j9vmthread 0x7f649931b700 publicFlags=181 privateFlags=0 inNative=0 // wait1
    !j9vmthread 0x7f6499324d00 publicFlags=181 privateFlags=0 inNative=0 // wait2
    !j9vmthread 0x7f649932d400 publicFlags=81 privateFlags=0 inNative=0 // locker
    !j9vmthread 0x7f649932b500 publicFlags=281 privateFlags=0 inNative=0 // b1
    !j9vmthread 0x7f649933c700 publicFlags=281 privateFlags=0 inNative=0 // b2
    !j9vmthread 0x7f6499345700 publicFlags=281 privateFlags=0 inNative=0 // b3
    !j9vmthread 0x7f649934dc00 publicFlags=281 privateFlags=0 inNative=0 // c1
    !j9vmthread 0x7f6499357300 publicFlags=281 privateFlags=0 inNative=0 // c2
    !j9vmthread 0x7f649935f900 publicFlags=281 privateFlags=0 inNative=0 // c3
    !j9vmthread 0x7f649934ac00 publicFlags=20081 privateFlags=0 inNative=0 // ds1
    !j9vmthread 0x7f649934bd00 publicFlags=20081 privateFlags=0 inNative=0 // ds2
    !j9vmthread 0x7f649933a600 publicFlags=20081 privateFlags=0 inNative=0 // ds3
    !j9vmthread 0x7f6499333900 publicFlags=20081 privateFlags=0 inNative=0 // ds4
    !j9vmthread 0x7f6499370f00 publicFlags=20081 privateFlags=0 inNative=0 // ds5
    !j9vmthread 0x7f6499378000 publicFlags=20081 privateFlags=0 inNative=0 // ds6
    !j9vmthread 0x7f6499380f00 publicFlags=281 privateFlags=0 inNative=0 // d1
    !j9vmthread 0x7f6499388f00 publicFlags=281 privateFlags=0 inNative=0 // d2
    !j9vmthread 0x7f6499392500 publicFlags=281 privateFlags=0 inNative=0 // d3
    !j9vmthread 0x7f649939ab00 publicFlags=281 privateFlags=0 inNative=0 // d4
    !j9vmthread 0x7f64993a4100 publicFlags=281 privateFlags=0 inNative=0 // d5
    !j9vmthread 0x7f64993ac700 publicFlags=281 privateFlags=0 inNative=0 // d6
    !j9vmthread 0x7f64993b5d00 publicFlags=281 privateFlags=0 inNative=0 // c1
    !j9vmthread 0x7f64993be400 publicFlags=281 privateFlags=0 inNative=0 // c2
    !j9vmthread 0x7f64993a1200 publicFlags=281 privateFlags=0 inNative=0 // c3
    !j9vmthread 0x7f6499390100 publicFlags=281 privateFlags=0 inNative=0 // c4
    !j9vmthread 0x7f64993ca900 publicFlags=281 privateFlags=0 inNative=0 // j1
    !j9vmthread 0x7f64993d2c00 publicFlags=281 privateFlags=0 inNative=0 // j2
    !j9vmthread 0x7f64993a9700 publicFlags=281 privateFlags=0 inNative=0 // j3
    !j9vmthread 0x7f64993e2000 publicFlags=281 privateFlags=0 inNative=0 // j4
    !j9vmthread 0x7f64993f3700 publicFlags=81 privateFlags=20081a inNative=0 // Finalizer thread

GC thread stacktrace

#0  0x00007f649c31e117 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f649c320e9b in pthread_cond_timedwait () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f649c177b9e in omrthread_sleep (millis=10) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/thread/common/omrthread.c:2447
#3  0x00007f648c5c8196 in MM_MetronomeDelegate::yieldWhenRequested (this=0x7f6498994988, env=0x7f6498998538) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_glue_java/MetronomeDelegate.cpp:73
#4  0x00007f648c344799 in MM_MemorySubSpaceMetronome::systemGarbageCollect (this=0x7f6498a7ee70, env=0x7f6498998538, gcCode=2) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_realtime/MemorySubSpaceMetronome.cpp:155
#5  0x00007f648c4bf8be in MM_MemorySpace::systemGarbageCollect (this=0x7f6498a7f1d0, env=0x7f6498998538, gcCode=2) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/gc/base/MemorySpace.cpp:400
#6  0x00007f648c49c691 in MM_Heap::systemGarbageCollect (this=0x7f6498070f60, env=0x7f6498998538, gcCode=2) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/gc/base/Heap.cpp:108
#7  0x00007f648c2c3de4 in j9gc_modron_global_collect_with_overrides (vmThread=0x7f6498a9a000, gcCode=2) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_base/modronapi.cpp:103
#8  0x00007f648c2f846d in MM_OwnableSynchronizerObjectList::ensureHeapWalkable (this=0x7f649899a540, env=0x7f6498998538) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_base/OwnableSynchronizerObjectList.cpp:177
#9  0x00007f648c2f8582 in MM_OwnableSynchronizerObjectList::rebuildList (this=0x7f649899a540, env=0x7f6498998538) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_base/OwnableSynchronizerObjectList.cpp:207
#10 0x00007f648c2f4457 in MM_GCExtensions::rebuildOwnableSynchronizerObjectList (this=0x7f6498065cb0, env=0x7f6498998538) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_base/GCExtensions.cpp:285
#11 0x00007f648c2f1317 in j9gc_ensureLockedSynchronizersIntegrity (vmThread=0x7f6498a9a000) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_base/VMInterfaceAPI.cpp:108
#12 0x00007f648bd5b52c in getArrayOfThreadInfo (env=0x7f6498a9a000, threadIDs=0x7f6499096d68, numThreads=20, getLockedMonitors=1 '\001', getLockedSynchronizers=1 '\001')
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/jcl/common/mgmtthread.c:854
#13 0x00007f648bd5ae40 in Java_com_ibm_java_lang_management_internal_ThreadMXBeanImpl_getMultiThreadInfoImpl (env=0x7f6498a9a000, beanInstance=0x7f6498c584a8, ids=0x7f6498c584a0, maxStackDepth=2147483647, getLockedMonitors=1 '\001', getLockedSynchronizers=1 '\001')
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/jcl/common/mgmtthread.c:685

The thread with VM access

#0  0x00007f649c3b542e in semtimedop () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6497cdef72 in semopWrapper (portLibrary=0x7f649c1ee260 <j9portLibrary>, semid=32789, sops=0x7f633ad77cca, nsops=1) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/port/sysvipc/j9SysvIPCWrappers.c:97
#2  0x00007f6497cd31de in j9shsem_wait (portLibrary=0x7f649c1ee260 <j9portLibrary>, handle=0x7f6308017420, semset=0, flag=0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/port/sysvipc/j9shsem.c:213
#3  0x00007f648bd336d4 in Java_openj9_internal_tools_attach_target_IPC_waitSemaphore (env=0x7f630802dc00, clazz=0x7f6498d7ed30) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/jcl/common/attach.c:500
#4  0x00007f6497f6fd56 in ffi_call_unix64 () at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/libffi/x86/unix64.S:105
#5  0x00007f6497f6f5cf in ffi_call_int (cif=0x7f633ad77ef0, fn=0x7f648bd33614 <Java_openj9_internal_tools_attach_target_IPC_waitSemaphore>, rvalue=0x7f630802dd18, avalue=0x7f633ad77f90, closure=0x0)
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/libffi/x86/ffi64.c:672
#6  0x00007f6497f6f650 in ffi_call (cif=0x7f633ad77ef0, fn=0x7f648bd33614 <Java_openj9_internal_tools_attach_target_IPC_waitSemaphore>, rvalue=0x7f630802dd18, avalue=0x7f633ad77f90)
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/libffi/x86/ffi64.c:691
#7  0x00007f6497e590e5 in VM_BytecodeInterpreterFull::cJNICallout (this=0x7f633ad78860, _sp=@0x7f633ad787e0: 0x7f630802da10, _pc=@0x7f633ad787e8: 0x7 <error: Cannot access memory at address 0x7>, receiverAddress=0x7f6498d7ed30, javaArgs=0x7f630802da38, 
    returnType=0x7f633ad7818b "\006", returnStorage=0x7f630802dd18, function=0x7f648bd33614 <Java_openj9_internal_tools_attach_target_IPC_waitSemaphore>, isStatic=true)

@dmitripivkine does this sound a problem because GC didn't acquire VM access first?

gacholio · 2026-03-30T13:09:58Z

Also not clear to me how this change could cause any problems in metronome - the assertion is more permissive than it was (and clearly isn't the issue) and the ifdef change also clearly has no effect on metronome.

gacholio · 2026-03-30T13:10:49Z

I suggest grinding the test with an without this change to prove it's an existing issue.

JasonFengJ9 · 2026-03-30T13:12:34Z

Also not clear to me how this change could cause any problems in metronome - the assertion is more permissive than it was (and clearly isn't the issue) and the ifdef change also clearly has no effect on metronome.

I ruled out the hang was caused by this change via restore the original code and just removed the assertion.
The hang happens when the assertion is removed.

gacholio · 2026-03-30T13:14:19Z

OK, once @dmitripivkine weighs in, I'll merge this.

JasonFengJ9 · 2026-03-30T13:14:31Z

I suggest grinding the test with an without this change to prove it's an existing issue.

Without this change, assertion failure occurred consistently (that's why it was a blocker issue)
It passes with -Xint (that's probably I didn't catch it at my local test initially)

gacholio · 2026-03-30T13:16:44Z

assertion failure occurred consistently

So the assertion failure was hiding the VM access issue. We should probably open a new issue for the underlying problem.

gacholio · 2026-03-30T13:17:22Z

May be worth looking into when this failure started to try an isolate the change that caused it.

JasonFengJ9 · 2026-03-30T13:17:35Z

OK, once @dmitripivkine weighs in, I'll merge this.

I feel an assertion failure is better than the hang to save machine resources.
If @dmitripivkine agrees the original assertion is correct, this PR might not be required, the fix probably should be in -Xgcpolicy:metronome area.

JasonFengJ9 · 2026-03-30T13:22:18Z

May be worth looking into when this failure started to try an isolate the change that caused it.

There was a recent GC change that affects -Xgcpolicy:metronome, @dmitripivkine might have details.

JasonFengJ9 · 2026-03-30T13:31:47Z

May be worth looking into when this failure started to try an isolate the change that caused it.

As per #23581 (comment)

Actually this was introduced the previous night where the xlinux builds failed due to disk space issues.
The failures are seen in internal builds on the night of the 23rd.

eclipse-openj9/openj9-omr@db4e137...1207e46
5354e07...d5c1a96

dmitripivkine · 2026-03-30T13:32:36Z

It seems GC has exclusive access without VM access, all other threads were halted but one of them has VM access.

In theory this is expected behaviour. There is a transfer of control between mutator thread triggered GC to Main GC dedicated thread. So, VM Access flag still be set for mutator thread requested exclusive and GC uses internal synchronization mechanisms after transfer of control. And there is complication of possible race between System GC request and scheduled GC increment. This logic is complicated (may be overcomplicated) and always was a point of attention.
@amicic FYI

However there should not be any connection with current issue. I think this updated assertion code should go in.
Different issue should be opened for hangs.

There was a recent GC change that affects -Xgcpolicy:metronome

@JasonFengJ9 Would you please refer to it?

JasonFengJ9 · 2026-03-30T13:35:01Z

There was a recent GC change that affects -Xgcpolicy:metronome

@JasonFengJ9 Would you please refer to it?

#23595 (comment)

dmitripivkine · 2026-03-30T13:58:40Z

There was a recent GC change that affects -Xgcpolicy:metronome

@JasonFengJ9 Would you please refer to it?

#23595 (comment)

Thank you!
eclipse-omr/omr#8132 modifies code related to GC start. Change itself is simple and unrelated but can change timing or coding layout and expose existing problem potentially.

#15173 removes Ownable Synchronizers support. This change is spreads widely across GC code but it is straight forward and should not have impact in this case.

dmitripivkine · 2026-03-30T14:08:07Z

I feel an assertion failure is better than the hang to save machine resources.
If @dmitripivkine agrees the original assertion is correct, this PR might not be required, the fix probably should be in -Xgcpolicy:metronome area.

Recent changes looks unrelated but I am going to review them again.
My question is: if this assertion is not new, why it starts manifest now, how it works before? It is hard to believe there is a path never taken before.

dmitripivkine · 2026-03-30T14:15:42Z

@JasonFengJ9 May I have access to the system core mentioned in #23595 (comment)?

dmitripivkine · 2026-03-30T14:42:45Z

Ah, I was blind: the hang is related with #15173 indeed. It occurs at attempt to perform System GC in order to rebuild Ownable Synchronizers list. This is new code path.

dmitripivkine · 2026-03-30T15:01:25Z

New code rebuilds Ownable Synchronizers list from scratch. In order to perform this it initiates System GC. And this synchronous System GC request caused hangs (or may be even incorrect VM Access transfer by some reason). We are looking to this issue. So it is possible this assertion change is not going to be needed after all.

JasonFengJ9 · 2026-03-30T15:52:08Z

May I have access to the system core mentioned in #23595 (comment)?

Here it is https://ibm.box.com/s/21va3gsnyjvrvkn9d42qr4gapxjhh70p
The file transferring was slooow.

dmitripivkine · 2026-03-30T15:55:06Z

May I have access to the system core mentioned in #23595 (comment)?

Here it is https://ibm.box.com/s/21va3gsnyjvrvkn9d42qr4gapxjhh70p The file transferring was slooow.

Thank you!

dmitripivkine · 2026-03-30T16:14:51Z

https://ibm.box.com/s/21va3gsnyjvrvkn9d42qr4gapxjhh70p

Unfortunately looks like this file is broken, I can not unzip it anywhere.
@JasonFengJ9 ok, please do not waste you time again. Now, when we know where to look it should be easier to figure out.

JasonFengJ9 · 2026-03-30T17:36:34Z

Unfortunately looks like this file is broken, I can not unzip it anywhere.

Initially I attempted to upload here which requires one of recognized suffix such as zip, and renamed the file but it is really not in zip format, sorry for the confusion.
@dmitripivkine it is an original core file.

dmitripivkine · 2026-03-31T19:23:51Z

C-stack for main GC thread shows exclusive request from jit code. There is the same problem as we got assertion at the first place. Now, with assertion loosen up, there is another manifestation of the problem in JIT code. Both components (VM and JIT) can not recognize that exclusive access has been taken already, particularly VM Access flag is set.

#0  0x00007f649c31e117 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f649c320a41 in pthread_cond_wait () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f649c17ce54 in monitor_wait_original (self=0x7f6498d83370, monitor=0x7f6498ac1318, millis=0, nanos=0, interruptible=0, callbackFunction=0x0, userData=0x0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/thread/common/omrthread.c:4741
#3  0x00007f649c17b9cc in monitor_wait (monitor=0x7f6498ac1318, millis=0, nanos=0, interruptible=0, callbackFunction=0x0, userData=0x0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/thread/common/omrthread.c:4578
#4  0x00007f649c17b7d5 in omrthread_monitor_wait (monitor=0x7f6498ac1318) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/thread/common/omrthread.c:4398
#5  0x00007f6497e13a6d in internalAcquireVMAccessNoMutexWithMask (vmThread=0x7f6330003c00, haltMask=2203649) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/vm/VMAccess.cpp:388
#6  0x00007f6497e13c5e in internalAcquireVMAccessWithMask (vmThread=0x7f6330003c00, haltMask=2203649) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/vm/VMAccess.cpp:417
#7  0x00007f648c96e16e in acquireVMAccessNoSuspend (vmThread=0x7f6330003c00) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/runtime/J9VMAccess.hpp:30
#8  0x00007f648cb8fa44 in acquireVMaccessIfNeeded (vmThread=0x7f6330003c00, isCompThread=TR_no) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/env/VMJ9.cpp:286
#9  0x00007f648cbac399 in TR_J9VMBase::acquireVMAccessIfNeeded (this=0x7f633000b7f0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/env/VMJ9.h:1343
#10 0x00007f648cba334e in TR_J9VMBase::acquireClassTableMutex (this=0x7f633000b7f0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/env/VMJ9.cpp:6537
#11 0x00007f648c96e052 in TR::ClassTableCriticalSection::ClassTableCriticalSection (this=0x7f63403fc220, fe=0x7f633000b7f0, locked=false) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/env/ClassTableCriticalSection.hpp:52
#12 0x00007f648c982bcc in jitHookClassUnload (hookInterface=0x7f6498012140, eventNum=71, eventData=0x7f63403fc490, userData=0x0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/compiler/control/HookedByTheJit.cpp:2126
#13 0x00007f649c4b86ce in J9HookDispatch (hookInterface=0x7f6498012140, taggedEventNum=71, eventData=0x7f63403fc490) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/util/hookable/hookable.cpp:237
#14 0x00007f648c5ca65f in MM_MetronomeDelegate::addDyingClassesToList (this=0x7f6498994988, env=0x7f6330005df8, classLoader=0x7f6498a83fe8, setAll=false, classUnloadListStart=0x0, classUnloadCountResult=0x7f63403fc4f8)
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_glue_java/MetronomeDelegate.cpp:524
#15 0x00007f648c5c98a3 in MM_MetronomeDelegate::processDyingClasses (this=0x7f6498994988, env=0x7f6330005df8, classUnloadCountResult=0x7f63403fc668, anonymousClassUnloadCountResult=0x7f63403fc670, classLoaderUnloadCountResult=0x7f63403fc678, 
    classLoaderUnloadListResult=0x7f63403fc680) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_glue_java/MetronomeDelegate.cpp:434
#16 0x00007f648c5ca9c6 in MM_MetronomeDelegate::unloadDeadClassLoaders (this=0x7f6498994988, envModron=0x7f6330005df8) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_glue_java/MetronomeDelegate.cpp:615
#17 0x00007f648c5c932d in MM_MetronomeDelegate::incrementalCollect (this=0x7f6498994988, env=0x7f6330005df8) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_glue_java/MetronomeDelegate.cpp:355
#18 0x00007f648c345d1d in MM_RealtimeGC::incrementalCollect (this=0x7f6498994780, env=0x7f6330005df8) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_realtime/RealtimeGC.cpp:298
#19 0x00007f648c3463b3 in MM_RealtimeGC::internalGarbageCollect (this=0x7f6498994780, env=0x7f6330005df8, subSpace=0x7f6498a7ee70, allocDescription=0x0) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_realtime/RealtimeGC.cpp:413
#20 0x00007f648c494314 in MM_Collector::garbageCollect (this=0x7f6498994780, env=0x7f6330005df8, callingSubSpace=0x7f6498a7ee70, allocateDescription=0x0, gcCode=2, objectAllocationInterface=0x0, baseSubSpace=0x0, context=0x0)
    at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/gc/base/Collector.cpp:496
#21 0x00007f648c3447f6 in MM_MemorySubSpaceMetronome::collect (this=0x7f6498a7ee70, env=0x7f6330005df8, gcCode=...) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_realtime/MemorySubSpaceMetronome.cpp:166
#22 0x00007f648c354f14 in MM_Scheduler::mainEntryPoint (this=0x7f6498993fa0, envModron=0x7f6330005df8) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/openj9/runtime/gc_realtime/Scheduler.cpp:931
#23 0x00007f648c4d2b4e in dispatcher_thread_proc2 (portLib=0x7f649c1ee260 <j9portLibrary>, info=0x7f649c26c930) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/gc/base/ParallelDispatcher.cpp:89
#24 0x00007f6497cf557a in omrsig_protect (portLibrary=0x7f649c1ee260 <j9portLibrary>, fn=0x7f648c4d29cc <dispatcher_thread_proc2(OMRPortLibrary*, void*)>, fn_arg=0x7f649c26c930, handler=0x7f6497daa885 <structuredSignalHandlerVM>, handler_arg=0x7f649800fc90, 
    flags=506, result=0x7f63403fcd00) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/port/unix/omrsignal.c:427
#25 0x00007f648c4d2d54 in dispatcher_thread_proc (info=0x7f649c26c930) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/gc/base/ParallelDispatcher.cpp:131
#26 0x00007f649c176df6 in thread_wrapper (arg=0x7f6498d83370) at /root/builds/jdk25-vmaccessassert-0329/openj9-openjdk-jdk25/omr/thread/common/omrthread.c:1739
#27 0x00007f649c321ac3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#28 0x00007f649c3b38d0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6

JasonFengJ9 · 2026-04-16T19:15:11Z

The fix is supplied by GC team.
Closing

JasonFengJ9 added the comp:vm label Mar 27, 2026

JasonFengJ9 requested a review from gacholio March 27, 2026 15:33

Update j9jni_deleteGlobalRef assertion check to allow exclusive access

a0b7de2

Ensure j9jni_deleteGlobalRef() caller has exclusive or VM access. Signed-off-by: Jason Feng <fengj@ca.ibm.com>

JasonFengJ9 force-pushed the vmaccessassert branch from cecfd64 to a0b7de2 Compare March 27, 2026 18:37

gacholio approved these changes Mar 27, 2026

View reviewed changes

JasonFengJ9 mentioned this pull request Mar 30, 2026

threadMXBeanTestSuite1 -Xgcpolicy:metronome j9vm.227 ASSERTION FAILED at vm/jnicsup.cpp:1691: ((vmThread)->publicFlags & J9_PUBLIC_FLAGS_VM_ACCESS) #23570

Closed

JasonFengJ9 marked this pull request as draft March 30, 2026 15:52

JasonFengJ9 closed this Apr 16, 2026

Conversation

JasonFengJ9 commented Mar 27, 2026

Uh oh!

gacholio commented Mar 27, 2026

Uh oh!

JasonFengJ9 commented Mar 27, 2026

Uh oh!

JasonFengJ9 commented Mar 27, 2026

Uh oh!

gacholio commented Mar 27, 2026

Uh oh!

dmitripivkine commented Mar 27, 2026

Uh oh!

JasonFengJ9 commented Mar 27, 2026

Uh oh!

JasonFengJ9 commented Mar 27, 2026

Uh oh!

gacholio commented Mar 27, 2026

Uh oh!

pshipton commented Mar 27, 2026

Uh oh!

gacholio commented Mar 28, 2026

Uh oh!

gacholio commented Mar 29, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

gacholio commented Mar 30, 2026

Uh oh!

gacholio commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

gacholio commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

gacholio commented Mar 30, 2026

Uh oh!

gacholio commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 30, 2026

Uh oh!

JasonFengJ9 commented Mar 30, 2026

Uh oh!

dmitripivkine commented Mar 31, 2026

Uh oh!

JasonFengJ9 commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

JasonFengJ9 commented Mar 30, 2026 •

edited

Loading

JasonFengJ9 commented Mar 30, 2026 •

edited

Loading