On Wed, 29 Mar 2023 02:40:09 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fixed trailing spaces in two files
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1554:
>
>> 1552: // Correct jt->jvmti_thread_state() and jt->jvmti_vthread() if
>> necessary.
>> 1553: // It was not maintained while notifyJvmti was disabled.
>> 1554: if (jt_state != ct_state && jt_state != vt_state) {
>
> Is it possible that jt_state == ct_state while the virtual thread is executed
> or vice versa? Just because jvmtt_state is outdated.
> Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled ==
> true?
A1: Not sure, I understand your first question correctly. What does mean "vice
versa" in this context?
When `notifyJvmti` events is disabled then a call to
`rebind_to_jvmti_thread_state_of` is omitted in VTMS transitions. So, we need
to correct it if necessary. It can be `jt_state == ct_state` while the virtual
thread is executed in a mount/unmount transition. I keep thinking on how to
make this fixup more precise.
A better approach would be something like this:
if (virt) {
if (jt_state != vt_state) {
jt->set_jvmti_thread_state(vt_state); // restore
jt->jvmti_thread_state()
jt->set_jvmti_vthread(vt_oop); // restore jt->jvmti_vthread()
if (vt_state != nullptr) {
vt_state->set_thread(jt); // restore JavaThread link
}
}
} else { // !virt
if (jt_state != ct_state) {
jt->set_jvmti_thread_state(ct_state); // restore
jt->jvmti_thread_state()
jt->set_jvmti_vthread(nullptr); // reset jt->jvmti_vthread()
}
}
But it does not work correctly now. Some adjustment is needed to make it
working.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1151712229
