RFR: JDK-8152690: main thread does not have native thread name
David Holmes
david.holmes at oracle.com
Mon Apr 18 04:40:36 UTC 2016
On 17/04/2016 8:38 PM, David Holmes wrote:
> On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote:
>> Hi David,
>>
>>> Need to hear from core-libs and/or launcher folk as this touches a
>>> number of pieces of code.
>>
>> I'm waiting more reviewer(s) .
>>
>> BTW, Should I make patches which are based on jdk9/dev repos?
>> My proposal includes hotspot changes.
>> So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot}
>> after reviewing.
>
> No, jdk9/hs please.
And it will need to go via JPRT so I will sponsor it for you.
Thanks,
David
> Thanks,
> David
>
>> I can update my webrev to adapt to jdk9/dev repos if need.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/04/17 7:20, David Holmes wrote:
>>> Hi Yasumasa,
>>>
>>> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote:
>>>> Hi David,
>>>>
>>>> I uploaded new webrev:
>>>>
>>>> - hotspot:
>>>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/
>>>>
>>>> - jdk:
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/
>>>
>>> Ah sneaky! :) Using JNI to by-pass access control so we can set up a
>>> private method to do the name setting, yet avoid any API change that
>>> would require a CCC request. I think I like it. :)
>>>
>>> Need to hear from core-libs and/or launcher folk as this touches a
>>> number of pieces of code.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>>
>>>>> it won't work unless you change the semantics of setName so I'm not
>>>>> sure what you were thinking here. To take advantage of an arg taking
>>>>> JVM_SetNativThreadName you would need to call it directly as no Java
>>>>> code will call it . ???
>>>>
>>>> I added a flag for setting native thread name to JNI-attached thread.
>>>> This change can set native thread name if main thread changes to
>>>> JNI-attached thread.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/04/16 16:11, David Holmes wrote:
>>>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote:
>>>>>> Hi David,
>>>>>>
>>>>>>> That change in behaviour may be a problem, it could be considered a
>>>>>>> regression that setName stops setting the native thread main, even
>>>>>>> though we never really intended it to work in the first place. :(
>>>>>>> Such
>>>>>>> a change needs to go through CCC.
>>>>>>
>>>>>> I understood.
>>>>>> Can I send CCC request?
>>>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.)
>>>>>
>>>>> Sorry you can't file a CCC request, you would need a sponsor for that.
>>>>> But at this stage I don't think I agree with the proposed change
>>>>> because of the change in behaviour - there's no way to restore the
>>>>> "broken" behaviour.
>>>>>
>>>>>> I want to continue to discuss about it on JDK-8154331 [1].
>>>>>
>>>>> Okay we can do that.
>>>>>
>>>>>>
>>>>>>> Further, we expect the launcher to use the supported JNI interface
>>>>>>> (as
>>>>>>> other processes would), not the internal JVM interface that exists
>>>>>>> for
>>>>>>> the JDK sources to communicate with the JVM.
>>>>>>
>>>>>> I think that we do not use JVM interface if we add new method in
>>>>>> LauncherHelper as below:
>>>>>> ----------------
>>>>>> diff -r f02139a1ac84
>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>>>> Wed Apr 13 14:19:30 2016 +0000
>>>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java
>>>>>> Sat Apr 16 11:25:53 2016 +0900
>>>>>> @@ -960,4 +960,8 @@
>>>>>> else
>>>>>> return md.toNameAndVersion() + " (" + loc + ")";
>>>>>> }
>>>>>> +
>>>>>> + static void setNativeThreadName(String name) {
>>>>>> + Thread.currentThread().setName(name);
>>>>>> + }
>>>>>
>>>>> You could also make that call via JNI directly, so not sure the helper
>>>>> adds much here. But it won't work unless you change the semantics of
>>>>> setName so I'm not sure what you were thinking here. To take advantage
>>>>> of an arg taking JVM_SetNativThreadName you would need to call it
>>>>> directly as no Java code will call it . ???
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> }
>>>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c
>>>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30
>>>>>> 2016 +0000
>>>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53
>>>>>> 2016 +0900
>>>>>> @@ -125,6 +125,7 @@
>>>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage);
>>>>>> static void ShowSettings(JNIEnv* env, char *optString);
>>>>>> static void ListModules(JNIEnv* env, char *optString);
>>>>>> +static void SetNativeThreadName(JNIEnv* env, char *name);
>>>>>>
>>>>>> static void SetPaths(int argc, char **argv);
>>>>>>
>>>>>> @@ -325,6 +326,7 @@
>>>>>> * mainThread.isAlive() to work as expected.
>>>>>> */
>>>>>> #define LEAVE() \
>>>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \
>>>>>> do { \
>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \
>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \
>>>>>> @@ -488,6 +490,9 @@
>>>>>> mainArgs = CreateApplicationArgs(env, argv, argc);
>>>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs);
>>>>>>
>>>>>> + /* Set native thread name. */
>>>>>> + SetNativeThreadName(env, "main");
>>>>>> +
>>>>>> /* Invoke main method. */
>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
>>>>>>
>>>>>> @@ -1686,6 +1691,22 @@
>>>>>> joptString);
>>>>>> }
>>>>>>
>>>>>> +/**
>>>>>> + * Set native thread name as possible.
>>>>>> + */
>>>>>> +static void
>>>>>> +SetNativeThreadName(JNIEnv *env, char *name)
>>>>>> +{
>>>>>> + jmethodID setNativeThreadNameID;
>>>>>> + jstring nameString;
>>>>>> + jclass cls = GetLauncherHelperClass(env);
>>>>>> + NULL_CHECK(cls);
>>>>>> + NULL_CHECK(setNativeThreadNameID =
>>>>>> (*env)->GetStaticMethodID(env, cls,
>>>>>> + "setNativeThreadName", "(Ljava/lang/String;)V"));
>>>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name));
>>>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID,
>>>>>> nameString);
>>>>>> +}
>>>>>> +
>>>>>> /*
>>>>>> * Prints default usage or the Xusage message, see
>>>>>> sun.launcher.LauncherHelper.java
>>>>>> */
>>>>>> ----------------
>>>>>>
>>>>>> So I want to add new arg to JVM_SetNativeThreadName().
>>>>>>
>>>>>>> However this is still a change to the exported JVM interface and so
>>>>>>> has to be approved.
>>>>>>
>>>>>> Do you mean that this change needs CCC?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2016/04/16 7:26, David Holmes wrote:
>>>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> I think it is a bug based on the comment here:
>>>>>>>>>
>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main
>>>>>>>>> thread and
>>>>>>>>> JNI attached threads
>>>>>>>>
>>>>>>>> I filed it to JBS as JDK-8154331.
>>>>>>>> I will send review request to hotspot-runtime-dev.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Though that will introduce a change in behaviour by itself as
>>>>>>>>> setName
>>>>>>>>> will no longer set the native name for the main thread.
>>>>>>>>
>>>>>>>> I know.
>>>>>>>
>>>>>>> That change in behaviour may be a problem, it could be considered a
>>>>>>> regression that setName stops setting the native thread main, even
>>>>>>> though we never really intended it to work in the first place. :(
>>>>>>> Such
>>>>>>> a change needs to go through CCC.
>>>>>>>
>>>>>>>> I checked changeset history.
>>>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is
>>>>>>>> backported JDK 8.
>>>>>>>
>>>>>>> Yes this all came in as part of the OSX port in 7u2.
>>>>>>>
>>>>>>>> However, this function seems to be called from
>>>>>>>> Thread#setNativeName()
>>>>>>>> only.
>>>>>>>> In addition, Thread#setNativeName() is private method.
>>>>>>>>
>>>>>>>> Thus I think that we can add an argument to
>>>>>>>> JVM_SetNativeThreadName()
>>>>>>>> for force setting.
>>>>>>>> (e.g. "bool forced")
>>>>>>>>
>>>>>>>> It makes a change of JVM API.
>>>>>>>> However, this function is NOT public, so I think we can add one
>>>>>>>> more
>>>>>>>> argument.
>>>>>>>>
>>>>>>>> What do you think about this?
>>>>>>>> If it is accepted, we can set native thread name from Java
>>>>>>>> launcher.
>>>>>>>
>>>>>>> The private/public aspect of the Java API is not really at issue.
>>>>>>> Yes
>>>>>>> we would add another arg to the JVM function to allow it to apply to
>>>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not
>>>>>>> just
>>>>>>> "force"). However this is still a change to the exported JVM
>>>>>>> interface
>>>>>>> and so has to be approved. Further, we expect the launcher to use
>>>>>>> the
>>>>>>> supported JNI interface (as other processes would), not the internal
>>>>>>> JVM interface that exists for the JDK sources to communicate with
>>>>>>> the
>>>>>>> JVM.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Yasumasa
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2016/04/15 19:16, David Holmes wrote:
>>>>>>>>> Hi Yasumasa,
>>>>>>>>>
>>>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>>> The fact that the "main" thread is not tagged as being a
>>>>>>>>>>> JNI-attached
>>>>>>>>>>> thread seems accidental to me
>>>>>>>>>>
>>>>>>>>>> Should I file it to JBS?
>>>>>>>>>
>>>>>>>>> I think it is a bug based on the comment here:
>>>>>>>>>
>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main
>>>>>>>>> thread and
>>>>>>>>> JNI attached threads
>>>>>>>>>
>>>>>>>>> Though that will introduce a change in behaviour by itself as
>>>>>>>>> setName
>>>>>>>>> will no longer set the native name for the main thread.
>>>>>>>>>
>>>>>>>>>> I think that we can fix as below:
>>>>>>>>>> ---------------
>>>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp
>>>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016
>>>>>>>>>> +0200
>>>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016
>>>>>>>>>> +0900
>>>>>>>>>> @@ -3592,7 +3592,7 @@
>>>>>>>>>> #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_thread_state(_thread_in_vm);
>>>>>>>>>> main_thread->initialize_thread_current();
>>>>>>>>>> // must do this before set_active_handles
>>>>>>>>>> @@ -3776,6 +3776,9 @@
>>>>>>>>>> // Notify JVMTI agents that VM initialization is complete -
>>>>>>>>>> nop if
>>>>>>>>>> no agents.
>>>>>>>>>> JvmtiExport::post_vm_initialized();
>>>>>>>>>>
>>>>>>>>>> + // Change attach status to "attached"
>>>>>>>>>> + main_thread->set_done_attaching_via_jni();
>>>>>>>>>> +
>>>>>>>>>
>>>>>>>>> I think we can do this straight after the JavaThread constructor.
>>>>>>>>>
>>>>>>>>>> if (TRACE_START() != JNI_OK) {
>>>>>>>>>> vm_exit_during_initialization("Failed to start tracing
>>>>>>>>>> backend.");
>>>>>>>>>> }
>>>>>>>>>> ---------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it wants to name its native threads then it is free to do so,
>>>>>>>>>>
>>>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread
>>>>>>>>>> name
>>>>>>>>>> when the caller thread is JNI-attached thread.
>>>>>>>>>> However, I think that it should be changed if Java developer
>>>>>>>>>> calls
>>>>>>>>>> Thread#setName() explicitly.
>>>>>>>>>> It is not the same of changing native thread name at
>>>>>>>>>> Threads::create_vm().
>>>>>>>>>>
>>>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below.
>>>>>>>>>> What do you think about this?
>>>>>>>>>
>>>>>>>>> The decision to not change the name of JNI-attached threads was a
>>>>>>>>> deliberate one** - this functionality originated with the OSX port
>>>>>>>>> and
>>>>>>>>> it was reported that the initial feedback with this feature was to
>>>>>>>>> ensure it didn't mess with thread names that had been set by the
>>>>>>>>> host
>>>>>>>>> process. If we do as you propose then we will just have an
>>>>>>>>> inconsistency for people to complain about: "why does my native
>>>>>>>>> thread
>>>>>>>>> only have a name if I call cur.setName(cur.getName()) ?"
>>>>>>>>>
>>>>>>>>> ** If you follow the bugs and related discussions on this, the
>>>>>>>>> semantics and limitations (truncation, current thread only,
>>>>>>>>> non-JNI
>>>>>>>>> threads only) of setting the native thread name were supposed
>>>>>>>>> to be
>>>>>>>>> documented in the release notes - but as far as I can see that
>>>>>>>>> never
>>>>>>>>> happened. :(
>>>>>>>>>
>>>>>>>>> My position on this remains that if it is desirable for the main
>>>>>>>>> thread (and DestroyJavaVM thread) to have native names then the
>>>>>>>>> launcher needs to be setting them using the available platform
>>>>>>>>> APIs.
>>>>>>>>> Unfortunately this is complicated - as evidenced by the VM code
>>>>>>>>> for
>>>>>>>>> this - due to the need to verify API availability.
>>>>>>>>>
>>>>>>>>> Any change in behaviour in relation to Thread.setName would have
>>>>>>>>> to go
>>>>>>>>> through our CCC process I think. But a change in the launcher
>>>>>>>>> would
>>>>>>>>> not.
>>>>>>>>>
>>>>>>>>> Sorry.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> ---------------
>>>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016
>>>>>>>>>> +0200
>>>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016
>>>>>>>>>> +0900
>>>>>>>>>> @@ -3187,7 +3187,7 @@
>>>>>>>>>> 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()) {
>>>>>>>>>> + if (Thread::current() == thr) {
>>>>>>>>>> // 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));
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Yasumasa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2016/04/15 13:32, David Holmes wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>> Roger,
>>>>>>>>>>>> Thanks for your comment!
>>>>>>>>>>>>
>>>>>>>>>>>> David,
>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>>>> exposing
>>>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to call Thread#setName() after initializing VM (before
>>>>>>>>>>>> calling
>>>>>>>>>>>> main method),
>>>>>>>>>>>> I could set native thread name.
>>>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we
>>>>>>>>>>>> can't
>>>>>>>>>>>> set
>>>>>>>>>>>> native thread name for DestroyJavaVM.
>>>>>>>>>>>
>>>>>>>>>>> Right - I came to the same realization earlier this morning.
>>>>>>>>>>> Which,
>>>>>>>>>>> unfortunately, takes me back to the basic premise here that we
>>>>>>>>>>> don't
>>>>>>>>>>> set the name of threads not created by the JVM. The fact that
>>>>>>>>>>> the
>>>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems
>>>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by
>>>>>>>>>>> accident for the initial attach, and can't be used for the
>>>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently
>>>>>>>>>>> named at
>>>>>>>>>>> the native level.
>>>>>>>>>>>
>>>>>>>>>>> I'm afraid my view here is that the launcher has to be treated
>>>>>>>>>>> like
>>>>>>>>>>> any other process that might host a JVM. If it wants to name its
>>>>>>>>>>> native threads then it is free to do so, but I would not be
>>>>>>>>>>> exporting
>>>>>>>>>>> a function from the JVM to do that - it would have to use the OS
>>>>>>>>>>> specific API's for that on a platform-by-platform basis.
>>>>>>>>>>>
>>>>>>>>>>> Sorry.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Comments:
>>>>>>>>>>>>>
>>>>>>>>>>>>> jvm.h: The function names are too similar but perform
>>>>>>>>>>>>> different
>>>>>>>>>>>>> functions:
>>>>>>>>>>>>>
>>>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName
>>>>>>>>>>>>>
>>>>>>>>>>>>> - The first function applies to the current thread, the
>>>>>>>>>>>>> second
>>>>>>>>>>>>> one a
>>>>>>>>>>>>> specific java thread.
>>>>>>>>>>>>> It would seem useful for there to be a comment somewhere
>>>>>>>>>>>>> about
>>>>>>>>>>>>> what
>>>>>>>>>>>>> the new function does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*)
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> (SetNativeThreadName0_t)
>>>>>>>>>>>>> as is done on unix and mac.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c:
>>>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs
>>>>>>>>>>>>> used at
>>>>>>>>>>>>> line 730
>>>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast
>>>>>>>>>>>>> on the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> line as dlsym...
>>>>>>>>>>>>>
>>>>>>>>>>>>> $.02, Roger
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>> That is an interesting question which I haven't had time to
>>>>>>>>>>>>>>> check -
>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached
>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of
>>>>>>>>>>>>>>> JNI-attached threads :( )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed
>>>>>>>>>>>>>> native
>>>>>>>>>>>>>> thread name (test) was set.
>>>>>>>>>>>>>> ---------
>>>>>>>>>>>>>> public class Sleep{
>>>>>>>>>>>>>> public static void main(String[] args) throws Exception{
>>>>>>>>>>>>>> Thread.currentThread().setName("test");
>>>>>>>>>>>>>> Thread.sleep(3600000);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> ---------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>>>> exposing
>>>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will update webrev after hearing Kumar's comment.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote:
>>>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for your comment.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name,
>>>>>>>>>>>>>>>>>> and JLI
>>>>>>>>>>>>>>>>>> uses it
>>>>>>>>>>>>>>>>>> in new webrev.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> need to
>>>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>> I'm waiting to review :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally I would have used a Java upcall to
>>>>>>>>>>>>>>>>> Thread.setName
>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes
>>>>>>>>>>>>>>>>> needed in
>>>>>>>>>>>>>>>>> that case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in
>>>>>>>>>>>>>>>> Thread#init(),
>>>>>>>>>>>>>>>> but I could not change native thread name.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>> name is not set.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is an interesting question which I haven't had time to
>>>>>>>>>>>>>>> check -
>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached
>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of
>>>>>>>>>>>>>>> JNI-attached threads :( )
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like
>>>>>>>>>>>>>>> exposing
>>>>>>>>>>>>>>> a new JVM function this way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus I think that we have to provide a function to set
>>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>>> thread name.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Could you review again?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - hotspot:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - jdk:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote:
>>>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on
>>>>>>>>>>>>>>>>>>> vacation).
>>>>>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we
>>>>>>>>>>>>>>>>>>> do not
>>>>>>>>>>>>>>>>>>> set the
>>>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the
>>>>>>>>>>>>>>>>>>> "main"
>>>>>>>>>>>>>>>>>>> thread.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>> Thanks Robbin,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" <robbin.ehn at oracle.com>:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks, looks good.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev.
>>>>>>>>>>>>>>>>>>>>>>> Could you review it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn"
>>>>>>>>>>>>>>>>>>>>>>>>> <robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>>:
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa,
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin,
>>>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn"
>>>>>>>>>>>>>>>>>>>>>>>>> <robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>
>>>>>>>>>>>>>>>>>>>>>>>>> >> <mailto:robbin.ehn at oracle.com
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com>>>:
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa,
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it:
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770
>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp
>>>>>>>>>>>>>>>>>>>>>>>>> Thu
>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24
>>>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016
>>>>>>>>>>>>>>>>>>>>>>>>> +0000
>>>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp
>>>>>>>>>>>>>>>>>>>>>>>>> Thu
>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24
>>>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016
>>>>>>>>>>>>>>>>>>>>>>>>> +0100
>>>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@
>>>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new
>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread();
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm);
>>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current();
>>>>>>>>>>>>>>>>>>>>>>>>> >> > +
>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main");
>>>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before
>>>>>>>>>>>>>>>>>>>>>>>>> set_active_handles
>>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size();
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block());
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something?
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread
>>>>>>>>>>>>>>>>>>>>>>>>> name in
>>>>>>>>>>>>>>>>>>>>>>>>> Thread
>>>>>>>>>>>>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName().
>>>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native
>>>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>>>>>> set at
>>>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already
>>>>>>>>>>>>>>>>>>>>>>>>> starte
>>>>>>>>>>>>>>>>>>>>>>>>> in VM.
>>>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in
>>>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread().
>>>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name
>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>> be the
>>>>>>>>>>>>>>>>>>>>>>>>> same.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like
>>>>>>>>>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>>>>>>>>> nicer, no?
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue
>>>>>>>>>>>>>>>>>>>>>>>>> Mar 29
>>>>>>>>>>>>>>>>>>>>>>>>> 09:43:05
>>>>>>>>>>>>>>>>>>>>>>>>> 2016
>>>>>>>>>>>>>>>>>>>>>>>>> +0200
>>>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed
>>>>>>>>>>>>>>>>>>>>>>>>> Mar 30
>>>>>>>>>>>>>>>>>>>>>>>>> 10:51:12
>>>>>>>>>>>>>>>>>>>>>>>>> 2016
>>>>>>>>>>>>>>>>>>>>>>>>> +0200
>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@
>>>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread
>>>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle
>>>>>>>>>>>>>>>>>>>>>>>>> thread_group,
>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread*
>>>>>>>>>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) {
>>>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name =
>>>>>>>>>>>>>>>>>>>>>>>>> "main";
>>>>>>>>>>>>>>>>>>>>>>>>> > Klass* k =
>>>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(),
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> true,
>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k);
>>>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop =
>>>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@
>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(),
>>>>>>>>>>>>>>>>>>>>>>>>> thread);
>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(),
>>>>>>>>>>>>>>>>>>>>>>>>> NormPriority);
>>>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop());
>>>>>>>>>>>>>>>>>>>>>>>>> > -
>>>>>>>>>>>>>>>>>>>>>>>>> > - Handle string =
>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main",
>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name);
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> > +
>>>>>>>>>>>>>>>>>>>>>>>>> > + Handle string =
>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL);
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID);
>>>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java'
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> naming
>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me.
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and
>>>>>>>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> process) is
>>>>>>>>>>>>>>>>>>>>>>>>> 'java' but
>>>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'.
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not
>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread.
>>>>>>>>>>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>>>>>>>>>>> waiting
>>>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with
>>>>>>>>>>>>>>>>>>>>>>>>> pthread_join().
>>>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread.
>>>>>>>>>>>>>>>>>>>>>>>>> So I
>>>>>>>>>>>>>>>>>>>>>>>>> think that
>>>>>>>>>>>>>>>>>>>>>>>>> we do
>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we
>>>>>>>>>>>>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>>>>>>>>>>> java and
>>>>>>>>>>>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might
>>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>> dependents.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc.
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4
>>>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND
>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java
>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main
>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java
>>>>>>>>>>>>>>>>>>>>>>>>> Main
>>>>>>>>>>>>>>>>>>>>>>>>> Thread'.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I do not think so.
>>>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher -
>>>>>>>>>>>>>>>>>>>>>>>>> e.g.
>>>>>>>>>>>>>>>>>>>>>>>>> Apache
>>>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I
>>>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>>>> that we
>>>>>>>>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code.
>>>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks again!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Robbin
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> > Thanks
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> > /Robbin
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin
>>>>>>>>>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > 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.
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review
>>>>>>>>>>>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT.
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor.
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
More information about the core-libs-dev
mailing list