On Mon, 1 May 2023 18:26:30 GMT, Alex Menkov <[email protected]> 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
