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

[TESTBUG] gtest pseudo-JavaThreads could be more regular JavaThreads

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 18
    • 13
    • hotspot
    • b06

      In the review for JDK-8214097 the curious nature of the gtest JavaThread subclasses was discussed - in particular their lack of a java.lang.Thread instance which means we have to be careful not to execute certain JavaThread code - e.g. exit().

      It was suggested these might be made more "normal".

      One way to do this would be to emulate what is done for the "service thread":

      void ServiceThread::initialize() {
        EXCEPTION_MARK;

        const char* name = "Service Thread";
        Handle string = java_lang_String::create_from_str(name, CHECK);

        // Initialize thread_oop to put it into the system threadGroup
        Handle thread_group (THREAD, Universe::system_thread_group());
        Handle thread_oop = JavaCalls::construct_new_instance(
                                SystemDictionary::Thread_klass(),
                                vmSymbols::threadgroup_string_void_signature(),
                                thread_group,
                                string,
                                CHECK);

        {
          MutexLocker mu(Threads_lock);
          ServiceThread* thread = new ServiceThread(&service_thread_entry);

          // At this point it may be possible that no osthread was created for the
          // JavaThread due to lack of memory. We would have to throw an exception
          // in that case. However, since this must work and we do not allow
          // exceptions anyway, check and abort if this fails.
          if (thread == NULL || thread->osthread() == NULL) {
            vm_exit_during_initialization("java.lang.OutOfMemoryError",
                                          os::native_thread_creation_failed_msg());
          }

          java_lang_Thread::set_thread(thread_oop(), thread);
          java_lang_Thread::set_priority(thread_oop(), NearMaxPriority);
          java_lang_Thread::set_daemon(thread_oop());
          thread->set_threadObj(thread_oop());
         _instance = thread;

          Threads::add(thread);
          Thread::start(thread);
        }

      Another thing to check is that these test threads can't terminate while the creating thread may still be interacting with them. In particular os::start_thread uses the startThread_lock() of the osThread, but if the new thread terminates and deletes itself it also deletes the startThread_lock, which may still be in use by the creating thread. For normal JavaThreads this cannot happen due to synchronization in the java.lang.Thread.start() method.

            dholmes David Holmes
            dholmes David Holmes
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: