ScopedMemoryAccess closeScope0 synchronization

[babsingh]

There are gaps where async exceptions are not processed in time (e.g.
JIT compiled code in a loop). Threads will wait in closeScope0 until
J9VMThread->scopedError (async exception) is transferred to
J9VMThread->currentException. The wait prevents a MemorySession to be
closed until no more operations are being performed on it.

Related: #13211

[tajila]

jenkins test sanity plinux jdk22

[tajila]

jenkins test sanity alinux jdk21

[gacholio]

The use of atomics seems unnecessary here, as you have a mutex. I'd also make the counter UDATA instead of U_64 (even though that makes no practical difference in this JDK level).

[babsingh]

The use of atomics seems unnecessary here, as you have a mutex. I'd also make the counter UDATA instead of U_64 (even though that makes no practical difference in this JDK level).

@gacholio Updated.

if (0 != vm->closeScopeNotifyCount) { // <--- Can this read happen outside monitor enter/exit?
	omrthread_monitor_enter(vm->closeScopeMutex);
	while (0 != vm->closeScopeNotifyCount) {
		omrthread_monitor_wait(vm->closeScopeMutex);
	}
	omrthread_monitor_exit(vm->closeScopeMutex);
}

[gacholio]

I'm also wondering how this global counter will work with multiple concurrent scope closures - we probably need to associate the count with the scope, either via internal hash table, or by adding a hidden field to the scope object.

[babsingh]

I'm also wondering how this global counter will work with multiple concurrent scope closures - we probably need to associate the count with the scope, either via internal hash table, or by adding a hidden field to the scope object.

• Only one thread will invoke closeScope0 (native) per SharedMemorySession. There is a CAS in SharedSession.java#L79-L87, which prevents multiple threads to invoke closeScope0 per MemorySession.
• At a time, a thread can only operate on max. two MemorySessions; see Ops-1 and Ops-2 for the various SharedMemorySession operations (i.e. methods with the @Scoped annotation).
• The common ScopedAccessError thrown for closing a MemorySession should close all the MemorySessions that need to be closed; the Java code wraps the MemorySession operations with the appropriate try/catch block.
• In our closeScope0 impl, if multiple MemorySessions are being closed concurrently and J9VMThread->scopedError is already set, we skip setting scopedError (see ScopedMemoryAccess.cpp#L77-L80) because operations on all scopes should stop in a thread once the thread throws J9VMThread->scopedError. Due to this approach, we don't need to track counts per MemorySession.
• The global counter tracks the number of threads that still need to throw the scopedError. The goal is to wait in closeScope0 until all scopedErrors are transferred to currentException.

[gacholio]

jenkins test sanity plinux jdk22

[gacholio]

jenkins test sanity alinux jdk21

[gacholio]

• closeScope0 per MemorySession.

Does this mean the native can be invoked on multiple threads (say each thread has its own session)?

[gacholio]

Nevermind, I see you've answered this.

[gacholio]

PPC is down - this has been sufficiently tested.