JDK-8154331 : main thread should be treated as JNI-attached thread.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-04-15
  • Updated: 2017-08-15
  • Resolved: 2017-08-15
Related Reports
Relates :  
Description
In discussion about JDK-8152690, we were found a bug.
Java main thread which is started by Java launcher is not treated as JNI-attached thread.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html
Comments
This is not on our list of current priorities. If this changes please re-open this issue. Closing as WNF.
15-08-2017

Suggested fix: ----------------------- --- old/src/share/vm/runtime/thread.cpp 2016-04-15 22:22:08.082191317 +0900 +++ new/src/share/vm/runtime/thread.cpp 2016-04-15 22:22:07.903192254 +0900 @@ -3592,7 +3592,8 @@ #endif // INCLUDE_JVMCI // Attach the main thread to this os thread - JavaThread* main_thread = new JavaThread(); + JavaThread* main_thread = new JavaThread(true); + main_thread->set_done_attaching_via_jni(); main_thread->set_thread_state(_thread_in_vm); main_thread->initialize_thread_current(); // must do this before set_active_handles
17-04-2016

Deferring to 10 is an option Update: the latest proposal for JDK-8152690 would potentially provide a reflection path to restore the functionality that would be lost - though access control may prevent that in some circumstances (ie security manager engaged).
16-04-2016

This would be a change in behavior that I didn't notice when I shepherded in the MacOS X port. Sorry about that. Since fixing it would be a change in behavior, I think it is too late to fix this in JDK9. We can fix this early in JDK10 in order to give any affected folks time to adapt.
16-04-2016

I think it was an oversight that when the OSX port brought this code in, the main thread was not marked as being a JNI-attached thread - as suggested by this comment: JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads However because of this oversight a call to Thread.setName from the main thread would cause the native thread name to be set (normally we don't modify JNI-attached threads). Correcting this behaviour could be seen as a regression because there would no be no way to set the native name of the main thread. Given that we don't actually gain anything by "fixing" this I'm inclined to simply leave it as-is.
16-04-2016