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

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

    XMLWordPrintable

Details

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

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: