JDK-8152690 : main thread does not have native thread name
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-03-24
  • Updated: 2023-08-11
  • Resolved: 2016-05-03
Related Reports
Relates :  
JDK-8154331 - main thread should be treated as JNI-attached thread.
Relates :  
JDK-7102541 - RFE: os::set_native_thread_name() cleanups
Relates :  
JDK-8314091 - Set native thread name for Java main thread
Description
HotSpot for Linux will set thread name via pthread_setname_np().
However, main thread does not have it.

All JavaThread have native name, and main thread is JavaThread.
For consistency, main thread should have native thread name.
Comments
On 26/04/2016 11:08 PM, David Holmes wrote: > On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> For this issue, I think we can approach as following: >> >> >> 1. Export new JVM function to set native thread name >> It can avoid JNI call and can handle char* value. >> However this plan has been rejected. >> >> 2. Call uncaught exception handler from Launcher >> We have to clear (process) any pending exception before >> DetachCurrentThread() call. (not documented?) >> ------ >>> so note that we are potentially calling DetachCurrentThread with an >>> exception pending - which is prohibited by JNI** >> >>> **JNI spec needs to be modified here. >> ------ >> So we can process pending exception through uncaught >> exception handler. >> However, this plan has been rejected. >> >> 3. Do not set DestroyJavaVM name when exception is occurred >> It disrupts consistency for native thread name. >> >> 4. Attach to JVM to set native thread name for DestroyJavaVM >> It does not look good. >> >> >> If all of them are not accepted, I guess that it is difficult. >> Do you have any other idea? > > Sorry I don't. The basic idea of having the launcher set the native > thread name is fine, but the mechanism to do that has been problematic. > The "real" solution (ie one that other applications hosting the jvm > would need to use) is for the launcher to duplicate the per-platform > logic for os::set_native_thread_name - but that was undesirable. Instead > we have tried to avoid that by finding a way to use whatever is already > in the JVM - but adding a new JVM interface to expose it directly is not > ideal; and hooking into the java.lang.Thread code to avoid that has run > into these other problems. I really don't want to take the logic for > uncaught exception handling that is in Thread::exit and duplicate it in > the launcher. > > The effort and disruption here really does not justify the "it would be > nice to set the native thread name for the main thread" objective. > > I never expected this to be as problematic as it has turned out. > > Sorry. Closing as "will not fix"
03-05-2016
Latest webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/
22-04-2016
Example output on Solaris: /scratch/dh198349/tests > ../jdk9-hs/build/solaris-x64/images/jdk/bin/java MainThread & [2] 6004 /scratch/dh198349/tests > main about to sleep /scratch/dh198349/tests > ps -L -o pid,lwp,lname,fname PID LWP LNAME COMMAND ... 6004 1 - java <= primordial launcher thread has no name 6004 2 main java 6004 3 GC Thread#0 java ... /scratch/dh198349/tests > Main thread renamed to MyMain about to sleep ps -L -o pid,lwp,lname,fname PID LWP LNAME COMMAND ... 6004 1 - java 6004 2 MyMain java <= this only happens because of JDK-8154331 ... /scratch/dh198349/tests > MyMain about to exit ps -L -o pid,lwp,lname,fname PID LWP LNAME COMMAND ... 6004 1 - java 6004 2 DestroyJavaVM java
20-04-2016
Awaiting reviews from JDK and launcher folk.
18-04-2016
Latest proposal adds a boolean, includeJNIThreads, to SetNativeThreadName which allows control over whether JNI-attached threads get their name set or not. This is exposed in the private java.lang.Thread.setNativeThreadName method which passes "false", but allows the launcher to call it via JNI, passing true. That allows the main thread and the DestroyJavaVM thread to have a native name set by their owning application.
18-04-2016
Thanks for your comment. Thread.setName() is called in JNI attached thread. So I cannot change native thread name. Thus I exported new JVM function JVM_SetNativeThreadName0(), and it is called by launcher in new webrev. I've sent review request to hotspot-runtime-dev maillist: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/018989.html
13-04-2016
Also note that the main thread created from the launcher will detach upon the return of main(String[] args) and then re-attach as the DestroyJavaVM thread. If we set the native thread name during VM initialization it would then be incorrect after the re-attach (due to not setting the name of JNI attached threads). I think a fix here belongs in the launcher itself, where it can invoke Thread.setName after the VM has been created, and again before calling DestroyJavaVM.
13-04-2016
The main thread does not belong to the JVM but to the process that loads the JVM. While this may be the Java launcher it may be a distinct application. The owning context for the main thread may have set the native name of the main thread for its own purposes and the JVM should not overwrite that. That is why we also do not set the native name of other threads that attach via JNI: JVM_ENTRY(void, JVM_SetNativeThreadName(JNIEnv* env, jobject jthread, jstring name)) JVMWrapper("JVM_SetNativeThreadName"); ResourceMark rm(THREAD); oop java_thread = JNIHandles::resolve_non_null(jthread); JavaThread* thr = java_lang_Thread::thread(java_thread); // Thread naming only supported for the current thread, doesn't work for // target threads. if (Thread::current() == thr && !thr->has_attached_via_jni()) { // we don't set the name of an attached thread to avoid stepping // on other programs const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); os::set_native_thread_name(thread_name); } JVM_END Arguably we could set it in the case that we recognize the launcher as the initiating process.
13-04-2016