On Wed, 29 Mar 2023 10:16:39 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> 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.
>
>> Shouldn't we always update (set to null) link/ jvmti_vthread if _enabled ==
>> true?
>
> A2: Ideally, all these corrections are only needed for the case: `_enable ==
> true.` I'm testing this now.
I've updated this part. Please. let me know if you still have some questions.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1152304909
