RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v9]

[Serguei Spitsyn]

On Mon, 1 May 2023 18:26:30 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates JVMTI FollowReferences implementation to report references from virtual threads:
>> - unmounted vthreads are detected, their stack references for JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL;
>> - stacks of mounted vthreads are splitted into 2 parts (virtual thread stack and carrier thread stack), references are reported with correct thread id/class tag/object tags/frame depth;
>> - common code to handle stack frames are moved into separate class;
>> 
>> Threads are reported as:
>> - platform threads: JVMTI_HEAP_REFERENCE_THREAD (as before);
>> - mounted vthreads (synthetic references, consider them as heap roots because carrier threads are roots): JVMTI_HEAP_REFERENCE_OTHER;
>> - unmounted vthreads: not reported as heap roots.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "no continuations" test case

src/hotspot/share/prims/jvmtiTagMap.cpp line 2796:

> 2794:   if (!java_thread->has_last_Java_frame()) {
> 2795:     // this may be only platform thread
> 2796:     assert(mounted_vt == nullptr, "must be");

I'm not sure this assert is right.
I think, a virtual thread may have an empty stack observable from a VM_op,
for instance when it is in a process of being terminated.
Though, it is not that easy to make this assert fired with a test case and prove this can happen.
Another danger is that a virtual thread can be observed from a VM_op as in a VTMS (mount/unmount) transition. I need to think a little bit about possible consequences. Is it better to treat current thread identity as of a carrier thread in such a case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1182242390