On Wed, 4 Oct 2023 21:59:54 GMT, Leonid Mesnik <[email protected]> wrote:
>> The JVMTI VirtualThreadStart events have to follow the ThreadStart events
>> pattern and so, should not be thread-filtered.
>> The fix includes:
>> - `jvmti.xml`: remov the attribute `filtered="thread"` in the
>> `VirtuallThreadStart` event spec
>> - `jvmtiEventController.cpp`: remove the `VTHREAD_START_BIT` from the
>> `THREAD_FILTERED_EVENT_BITS` mask and and it to the
>> `NEED_THREAD_LIFE_EVENTS` mask
>> - `jvmtiExport.cpp`: rearrangements in the
>> `JvmtiExport::post_vthread_start()` function
>>
>> The fix also includes a couple of minor unification tweaks:
>> - to align `JvmtiExport::post_thread_end()` with
>> `JvmtiExport::post_vthread_end()` which have a little bit more optimized
>> check for the `JVMTI_PHASE_PRIMORDIAL`.
>> - to rename the local variable `cur_thread` as `thread` to follow the
>> common pattern in `JvmtiExport::post_vthread_start()` and
>> `JvmtiExport::post_vthread_end()`
>>
>> Testing: ran mach5 tiers 1-6. All tests are passed.
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1552:
>
>> 1550: JvmtiEnvThreadStateIterator it(state);
>> 1551: for (JvmtiEnvThreadState* ets = it.first(); ets != nullptr; ets =
>> it.next(ets)) {
>> 1552: JvmtiEnv *env = ets->get_env();
>
> This change as well as renaming cur_thread are not related to the main issue.
> It would be better to separate them. Easier to track and backport if needed.
> They are mentioned in PR but not in jira bug, hard to find the reason
> without GitHub. Might be better to copy them in the bug if you want to keep
> them.
Thanks. I agree with you in general.
The whole fix is relatively small, so I'd prefer to keep such a minor cleanup
in this particular case.
I'll update the bug report with this info.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16019#discussion_r1349184898
