On Tue, 22 Nov 2022 05:57:37 GMT, Serguei Spitsyn <[email protected]> wrote:
>> The can_support_virtual_thread was initially implemented as an onload
>> capability.
>> It is why this capability does not work for the agents loaded into running
>> VM.
>> The fix is to move it from `onload` to `always`capabilities list.
>>
>> Testing:
>> New test is added: VirtualStartThreadTest.
>> TBD: mach5 jvmti, jdi and tier1-6 tests.
>
> Serguei Spitsyn has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains eight additional
> commits since the last revision:
>
> - Merge branch 'master' into br19
> Merge
> - removed thread->vthread() != NULL from JvmtiVirtualThreadEventMark
> constructor
> - minor update for unnamed threads in jvmti_common.h
> - fixed a trailing white space issue
> - extended VirtualThreadStartTest to support more configs; fixed issue in
> jvmtiExport.cpp
> - roll back unintended VirtualThread.java file update
> - simplified VirtualThreadStartTest
> - 8296323: JVMTI can_support_virtual_threads not available for agents loaded
> into running VM
src/hotspot/share/prims/jvmtiExport.cpp line 202:
> 200: JvmtiEventMark(thread) {
> 201: _jthread = to_jobject(thread->vthread());
> 202: assert(thread->vthread() != NULL || thread->threadObj() == NULL,
> "sanity check");
Seems a little strange to me that L202 is after L201. You're asserting
that `thread->vthread() != NULL` after passing it to a `to_jobject()` call.
-------------
PR: https://git.openjdk.org/jdk/pull/11246
