JVMTI suspend and resume rework to remove the virtual thread list

[babsingh]

This proposal updates the JVMTI suspend and resume mechanism for virtual threads so that it no longer has to rely on the virtual thread list. The end goal is to improve performance by removing the virtual thread list.

1. Declare a global variable in J9JavaVM: allVirtualThreadsSuspended.
2. In jvmtiSuspendAllVirtualThreads, set allVirtualThreadsSuspended to TRUE, and scan all carrier threads to suspend mounted virtual threads (similar to jvmtiGetAllThreads).
3. In jvmtiResumeAllVirtualThreads, set allVirtualThreadsSuspended to FALSE, and scan all carrier threads to resume mounted virtual threads (similar to jvmtiGetAllThreads).
4. In JVM_VirtualThreadMountEnd, set halt flag in the current J9VMThread if allVirtualThreadsSuspended is set to TRUE.
5. In jvmtiResumeThread, set java.lang.VirtualThread.isSuspendedByJVMTI to a specific value, which will allow to mount the thread, if allVirtualThreadsSuspended is set to TRUE. If the virtual thread is already mounted, only the halt flag needs to be cleared.
6. In jvmtiSuspendThread, reset java.lang.VirtualThread.isSuspendedByJVMTI if allVirtualThreadsSuspended is set to TRUE.
7. In jvmtiGetThreadState, inspect allVirtualThreadsSuspended and java.lang.VirtualThread.isSuspendedByJVMTI for setting the SUSPEND flag.

[babsingh]

fyi @fengxue-IS @tajila @gacholio

[babsingh]

The above approach won't work because:

• it will suspend new virtual threads which are created after jvmtiSuspendAllVirtualThreads (from @fengxue-IS); and
• it won't support the except_list.

Another approach:

jvmtiSuspendAllVirtualThreads {
   // Acquire Exclusive VM Access (EVMA)
   // Set halt flag for all virtual threads mounted on a carrier thread minus virtual threads in the except_list
   // Walk heap to suspend all unmounted carrier threads minus virtual threads in the except_list
   // Release EVMA
}

jvmtiResumeAllVirtualThreads {
   // Acquire EVMA
   // Clear halt flag for all virtual threads mounted on a carrier thread minus virtual threads in the except_list
   // Walk heap to resume all unmounted carrier threads minus virtual threads in the except_list
   // Release EVMA
}

@gacholio Is it fine to set the J9_PUBLIC_FLAGS_HALT_THREAD_JAVA_SUSPEND flag under Exclusive VM Access?

[gacholio]

It's not a bit, it's a mask of all halt bits excluding the suspend flag.

[babsingh]

It's not a bit, it's a mask of all halt bits excluding the suspend flag.

I don't fully understand this statement due to lack of knowledge of VM access implementation. @gacholio Can you elaborate a little more? Does this mean we cannot suspend J9VMThreads under exclusive VM access?

[gacholio]

I think the EVMA approach will work.

[gacholio]

When you say "walk the heap" what do you mean? Walk the continuation list, or a linear walk of the entire heap?

[babsingh]

I was thinking of a Linear walk of the entire heap since it will also cover virtual threads that haven't started i.e. they haven't been added to the virtual thread list or the continuation list. @amicic @dmitripivkine @LinHu2016 Will it be possible to walk the continuation list from JVMTI? Will it work to suspend virtual threads considering it has weak references?

#16855 a reference to Thread is introduced in the Continuation class.

[gacholio]

I'm wondering about dark matter - we have a special mode that keep the heap in a walkable state, but I can't recall what exactly that entails (i.e. what issues we might have if we're not in the safe mode).

[fengxue-IS]

I was thinking of a Linear walk of the entire heap since it will also cover virtual threads that haven't started i.e. they haven't been added to the virtual thread list or the continuation list. @amicic @dmitripivkine @LinHu2016 Will it be possible to walk the continuation list from JVMTI? Will it work to suspend virtual threads considering it has weak references?

#16855 a reference to Thread is introduced in the Continuation class.

I've wrote the refactor PR to depend on GC list in JVMTI, if we use EVMA, then there shouldn't be any problems with that approach, heap walk doesn't seem to be needed in this case as we already have access to GC's list. weak reference doesn't matter since we are just setting fields in the vthread object for unmounted one right?

[dmitripivkine]

I don't think linear walk of the heap is a good idea.
In general it requires, at least:

• flush all TLHs
• ability to handle dark matter (dead objects with obsolete fields except j9class with RAM section of it available only, so it is used to get size of the dead object to find the beginning of the next one)
• it is very-very slow (single thread walk I presume)? It would be comparable in time to execute full Global GC (and get up-to-date list)
  Walking of GC built list(s) however should work at any time I think. About-to-die objects can be discovered however

[babsingh]

I didn't realize that @fengxue-IS has already updated the JVMTI functions in #16855. The change to iterate through the continuations list LGTM. We will have to set the Continuation.vthread field from the VirtualThread constructor where the Continuation object is created. This will allow us to track virtual threads that haven't started yet from jvmtiSuspendAllVirtualThreads. Also, the global inspection lock won't be needed in #16855 with the exclusive VM approach.

[gacholio]

Does the previous comment mean this PR is unnecessary now?

[babsingh]

Does the previous comment mean this PR is unnecessary now?

This is just an issue. #16855 (PR) will close this issue once it employs EVMA in the JVMTI functions and initialization support for the Continuation.vthread field (extension repo change).

[tajila]

@babsingh can we close this issue?

[babsingh]

Yes, it was fixed with #16855.