Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8268902

Testing for threadObj != NULL is unnecessary in suspend handshake

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 18
    • 18
    • hotspot
    • None
    • b04

      The suspend handshake code tests if the JavaThread->is_exiting or that the threadObj() is null. Ever since JDK-8244997, once the JavaThread is running, the _threadObj won't be null until JavaThread is destroyed. So testing is_exiting is all you need to do.

      To get the JavaThread, the suspend code uses the field in the already created threadObj.

      JvmtiExport::cv_external_thread_to_JavaThread(ThreadsList * t_list, jthread thread
      ...
        oop thread_oop = JNIHandles::resolve_external_guard(thread);
        if (thread_oop == NULL) {
          // NULL jthread, GC'ed jthread or a bad JNI handle.
          return JVMTI_ERROR_INVALID_THREAD;
        }
      ...
        JavaThread * java_thread = java_lang_Thread::thread(thread_oop);
        if (java_thread == NULL) {
          // The java.lang.Thread does not contain a JavaThread * so it has
          // not yet run or it has died.
          return JVMTI_ERROR_THREAD_NOT_ALIVE;
        }

      We detach C++ JavaThread from threadOop when the thread joins in ensure_join but we don't detach threadObj from JavaThread until the JavaThread is destroyed.

      In gtest, the test JavaThread doesn't create a _threadObj JDK-8215948 so removing this unnecessary test allows writing gtests for suspend handshakes.

            coleenp Coleen Phillimore
            coleenp Coleen Phillimore
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: