RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v8]

Serguei Spitsyn sspitsyn at openjdk.org
Wed Mar 29 10:21:39 UTC 2023


On Wed, 29 Mar 2023 02:40:09 GMT, Leonid Mesnik <lmesnik at 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


More information about the serviceability-dev mailing list