-
Enhancement
-
Resolution: Fixed
-
P4
-
13
-
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.
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.
- relates to
-
JDK-8223481 gtest/GTestWrapper.java failed due to "assert(ret == 0) failed: sem_post failed; error='Invalid argument' (errno=EINVAL)"
-
- Closed
-
-
JDK-8269466 Factor out the common code for initializing and starting internal VM JavaThreads
-
- Resolved
-
-
JDK-8214097 Rework thread initialization and teardown logic
-
- Resolved
-