RFR: JDK-8152690: main thread does not have native thread name
David Holmes
david.holmes at oracle.com
Tue Apr 26 05:16:05 UTC 2016
On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote:
> Hi David, Kumar,
>
> I think that we should evacuate original exception before DestroyJavaVM
> thread name is set.
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/
> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/
>
> I added it to LEAVE macro in new webrev.
BTW: in the LEAVE macro, stylistically all the code should be in the do
{ } while(false); loop. I overlooked that initially.
> I tested it with following code. It works fine.
>
> -------------
> public void main(String[] args){
> throw new RuntimeException("test");
> }
> -------------
>
> What do you think about it?
I thought about being able to save/restore the original pending
exception but could not see a simple way to restore it - ie just by
poking it back into the thread's pending exception field. The problem
with using env->Throw is that it acts like the initial throwing of the
exception and will have a number of side-effects that then get doubled up:
- logging statements (UL and Event logging)
- OOM counting
I'm not sure whether that is acceptable or not
That aside you should check if orig_throwable is non-null before
clearing to avoid an unnecessary JNI call.
Also "Resume original exception" -> "Restore any original exception"
Thanks,
David
-----
>
> Thanks,
>
> Yasumasa
>
>
> On 2016/04/26 11:16, David Holmes wrote:
>> Hi Yasumasa, Kumar,
>>
>> Turns out this change breaks the behaviour of the launcher in the case
>> that main() completes by throwing an exception.
>>
>> What we have in the launcher is:
>>
>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1;
>> LEAVE();
>>
>> where LEAVE would have expanded to:
>>
>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \
>> JLI_ReportErrorMessage(JVM_ERROR2); \
>> ret = 1; \
>> } \
>> if (JNI_TRUE) { \
>> (*vm)->DestroyJavaVM(vm); \
>> return ret; \
>> } \
>>
>> so note that we are potentially calling DetachCurrentThread with an
>> exception pending - which is prohibited by JNI**, but which we
>> actually rely on for desired operation as DetachCurrentThread calls
>> thread->exit() which performs uncaught exception handling (ie it
>> prints the exception message and stacktrace) and then clears the
>> exception! (Hence DestroyJavaVM is not called with any pending
>> exceptions.)
>>
>> **JNI spec needs to be modified here.
>>
>> With the current change we have now inserted the following at the
>> start of LEAVE:
>>
>> SetNativeThreadName(env, "DestroyJavaVM"); \
>> if ((*env)->ExceptionOccurred(env)) { \
>> (*env)->ExceptionClear(env); \
>> } \
>>
>> this has two unintended consequences:
>>
>> 1. SetNativeThreadName itself calls a number of JNI methods, with the
>> exception pending - which is not permitted. So straight away where we
>> have:
>>
>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread"));
>>
>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls
>> using the VM's CHECK_NULL macro - which checks for a pending exception
>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then
>> reports a JNI error:
>>
>> Error: A JNI error has occurred, please check your installation and
>> try again
>>
>>
>> 2. There is no longer an exception from main() for DetachCurrentThread
>> to report, so we exit with a return code of 1 as required, but don't
>> report the exception message/stacktrace.
>>
>> I don't see a reasonable solution for this other than abandoning the
>> attempt to change the name from "main" to "DestroyJavaVM" - which if
>> we can't do, I question the utility of setting the name in the first
>> place (while it might be useful in some circumstances [when main() is
>> running] it will cause confusion in others [when main() has exited]).
>>
>> David
>> -----
>>
>> On 25/04/2016 3:47 PM, David Holmes wrote:
>>> Looks good to me.
>>>
>>> I'll sponsor this "tomorrow".
>>>
>>> Thanks,
>>> David
>>>
>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote:
>>>> Hi Kumar,
>>>>
>>>> Thank you for your comment!
>>>> I've fixed them and uploaded new webrev. Could you review again?
>>>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote:
>>>>>
>>>>> Also a couple of minor suggestions:
>>>>>
>>>>> - * Set native thread name as possible.
>>>>> + * Set native thread name if possible.
>>>>>
>>>>>
>>>>> + /*
>>>>> - * We can clear pending exception because exception at this
>>>>> point
>>>>> - * is not critical.
>>>>> + */
>>>>>
>>>>> + /*
>>>>> + * Clear non critical pending exceptions at this point.
>>>>> + */
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This is in the wrong place:
>>>>>>
>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) {
>>>>>> 1716 /*
>>>>>> 1717 * We can clear pending exception because exception at
>>>>>> this point
>>>>>> 1718 * is not critical.
>>>>>> 1719 */
>>>>>> 1720 (*env)->ExceptionClear(env);
>>>>>> 1721 }
>>>>>>
>>>>>> This above needs to be after
>>>>>> 391 SetNativeThreadName(env, "main");
>>>>>> 392
>>>>>>
>>>>>> Here is why, supposing 1704 through 1711, returns a NULL,
>>>>>> but have also encountered an exception. In which case
>>>>>> the method SetNativeThreadName will return to the caller, as
>>>>>> if nothing has happened, because NULL_CHECK simply checks for NULL
>>>>>> and returns to the caller. This will cause the caller to enter
>>>>>> the VM with exceptions.
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>>
>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> I don't think we need to report the exception, but can just ignore
>>>>>>>> it. Either way we have to clear the exception before continuing.
>>>>>>>
>>>>>>> I've fixed it in new webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> On 2016/04/22 15:33, David Holmes wrote:
>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I have uploaded webrev.04 as below.
>>>>>>>>> Could you review again?
>>>>>>>>>
>>>>>>>>> > - hotspot:
>>>>>>>>> >
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/
>>>>>>>>>
>>>>>>>>
>>>>>>>> Looks fine.
>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > - jdk:
>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/
>>>>>>>>
>>>>>>>> As per private email (but repeated here on the record) in java.c:
>>>>>>>>
>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) {
>>>>>>>> 1716 JLI_ReportExceptionDescription(env);
>>>>>>>> 1717 }
>>>>>>>>
>>>>>>>> I don't think we need to report the exception, but can just ignore
>>>>>>>> it. Either way we have to clear the exception before continuing.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Yasumasa
>>>>>>>>>
>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" <yasuenag at gmail.com
>>>>>>>>> <mailto:yasuenag at gmail.com>>:
>>>>>>>>> >
>>>>>>>>> > Hi David,
>>>>>>>>> >
>>>>>>>>> > Thank you for your comment.
>>>>>>>>> > I uploaded new webrev. Could you review again?
>>>>>>>>> >
>>>>>>>>> > - hotspot:
>>>>>>>>> >
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > - jdk:
>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >> That aside I'm not sure why you do this so late in the
>>>>>>>>> process, I
>>>>>>>>> would have done it immediately after here:
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > I think that native thread name ("main") should be set just
>>>>>>>>> before
>>>>>>>>> > main method call.
>>>>>>>>> > However, main thread is already started, so I moved it as you
>>>>>>>>> suggested.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >> One thing I dislike about the current structure is that we
>>>>>>>>> have to
>>>>>>>>> go from char* to java.lang.String to call setNativeName which then
>>>>>>>>> calls
>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a
>>>>>>>>> char* !
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > SoI proposed to export new JVM function to set native thread
>>>>>>>>> name with
>>>>>>>>> > const char *.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> >
>>>>>>>>> > Yasumasa
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote:
>>>>>>>>> >>
>>>>>>>>> >> Hi Yasumasa,
>>>>>>>>> >>
>>>>>>>>> >> Thanks for persevering with this to get it into the current
>>>>>>>>> form.
>>>>>>>>> Sorry I haven't been able to do a detailed review until now.
>>>>>>>>> >>
>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Hi Gerard,
>>>>>>>>> >>>
>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" <gerard.ziemski at oracle.com
>>>>>>>>> <mailto:gerard.ziemski at oracle.com>
>>>>>>>>> >>> <mailto:gerard.ziemski at oracle.com
>>>>>>>>> <mailto:gerard.ziemski at oracle.com>>>:
>>>>>>>>> >>> >
>>>>>>>>> >>> > hi Yasumasa,
>>>>>>>>> >>> >
>>>>>>>>> >>> > Nice work. I have 2 questions:
>>>>>>>>> >>> >
>>>>>>>>> >>> > ========
>>>>>>>>> >>> > File: java.c
>>>>>>>>> >>> >
>>>>>>>>> >>> > #1 Shouldn’t we be checking for
>>>>>>>>> “(*env)->ExceptionOccurred(env)”
>>>>>>>>> >>> after every single JNI call? In this example instead of
>>>>>>>>> NULL_CHECK,
>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro?
>>>>>>>>> >>>
>>>>>>>>> >>> It is not critical if we encounter error at JNI function call
>>>>>>>>> because
>>>>>>>>> >>> we cannot set native thread name only.
>>>>>>>>> >>> So I think that we do not need to leave from launcher
>>>>>>>>> process.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> I agree we do not need to abort if an exception occurs (and in
>>>>>>>>> fact
>>>>>>>>> I don't think an exception is even possible from this code),
>>>>>>>>> but we
>>>>>>>>> should ensure any pending exception is cleared before any
>>>>>>>>> futher JNI
>>>>>>>>> calls might be made. Note that NULL_CHECK is already used
>>>>>>>>> extensively
>>>>>>>>> throughout the launcher code - so if this usage is wrong then it
>>>>>>>>> is all
>>>>>>>>> wrong! More on this code below ...
>>>>>>>>> >>
>>>>>>>>> >> Other comments:
>>>>>>>>> >>
>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp
>>>>>>>>> >>
>>>>>>>>> >> Please add a comment to the method now that you removed the
>>>>>>>>> internal
>>>>>>>>> comment:
>>>>>>>>> >>
>>>>>>>>> >> // Sets the native thread name for a JavaThread. If
>>>>>>>>> specifically
>>>>>>>>> >> // requested JNI-attached threads can also have their native
>>>>>>>>> name set;
>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may
>>>>>>>>> interfere
>>>>>>>>> >> // with the application that created them.
>>>>>>>>> >>
>>>>>>>>> >> ---
>>>>>>>>> >>
>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java
>>>>>>>>> >>
>>>>>>>>> >> Please add the following comments:
>>>>>>>>> >>
>>>>>>>>> >> + // Don't modify JNI-attached threads
>>>>>>>>> >> setNativeName(name, false);
>>>>>>>>> >>
>>>>>>>>> >> + // May be called directly via JNI or reflection (when
>>>>>>>>> permitted) to
>>>>>>>>> >> + // allow JNI-attached threads to set their native name
>>>>>>>>> >> private native void setNativeName(String name, boolean
>>>>>>>>> allowAttachedThread);
>>>>>>>>> >>
>>>>>>>>> >> ---
>>>>>>>>> >>
>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c
>>>>>>>>> >>
>>>>>>>>> >> 328 #define LEAVE() \
>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \
>>>>>>>>> >>
>>>>>>>>> >> I was going to suggest this be set later, but realized we have
>>>>>>>>> to be
>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :)
>>>>>>>>> >>
>>>>>>>>> >> + /* Set native thread name. */
>>>>>>>>> >> + SetNativeThreadName(env, "main");
>>>>>>>>> >>
>>>>>>>>> >> The comment is redundant given the name of the method. That
>>>>>>>>> aside
>>>>>>>>> I'm not sure why you do this so late in the process, I would have
>>>>>>>>> done
>>>>>>>>> it immediately after here:
>>>>>>>>> >>
>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) {
>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1);
>>>>>>>>> >> 388 exit(1);
>>>>>>>>> >> 389 }
>>>>>>>>> >> + SetNativeThreadName(env, "main");
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> + /**
>>>>>>>>> >> + * Set native thread name as possible.
>>>>>>>>> >> + */
>>>>>>>>> >>
>>>>>>>>> >> Other than the as->if change I'm unclear where the "possible"
>>>>>>>>> bit
>>>>>>>>> comes into play - why would it not be possible?
>>>>>>>>> >>
>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env,
>>>>>>>>> "java/lang/Thread"));
>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID =
>>>>>>>>> (*env)->GetStaticMethodID(env,
>>>>>>>>> cls,
>>>>>>>>> >> 1707 "currentThread",
>>>>>>>>> "()Ljava/lang/Thread;"));
>>>>>>>>> >> 1708 NULL_CHECK(currentThread =
>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls,
>>>>>>>>> >> 1709 currentThreadID));
>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env,
>>>>>>>>> cls,
>>>>>>>>> >> 1711 "setNativeName",
>>>>>>>>> "(Ljava/lang/String;Z)V"));
>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env,
>>>>>>>>> name));
>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread,
>>>>>>>>> setNativeNameID,
>>>>>>>>> >> 1714 nameString, JNI_TRUE);
>>>>>>>>> >>
>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for and
>>>>>>>>> clear
>>>>>>>>> any pending exception after CallVoidMethod.
>>>>>>>>> >>
>>>>>>>>> >> One thing I dislike about the current structure is that we
>>>>>>>>> have to
>>>>>>>>> go from char* to java.lang.String to call setNativeName which then
>>>>>>>>> calls
>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a
>>>>>>>>> char* !
>>>>>>>>> Overall I wonder about the affect on startup cost. But if there
>>>>>>>>> is an
>>>>>>>>> issue we can revisit this.
>>>>>>>>> >>
>>>>>>>>> >> Thanks,
>>>>>>>>> >> David
>>>>>>>>> >> -----
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> > #2 Should the comment for “SetNativeThreadName” be “Set
>>>>>>>>> native
>>>>>>>>> thread
>>>>>>>>> >>> name if possible.” not "Set native thread name as possible.”?
>>>>>>>>> >>>
>>>>>>>>> >>> Sorry for my bad English :-)
>>>>>>>>> >>>
>>>>>>>>> >>> Thanks,
>>>>>>>>> >>>
>>>>>>>>> >>> Yasumasa
>>>>>>>>> >>>
>>>>>>>>> >>> > cheers
>>>>>>>>> >>> >
>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga
>>>>>>>>> <yasuenag at gmail.com <mailto:yasuenag at gmail.com>
>>>>>>>>> >>> <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>>
>>>>>>>>> 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/
>>>>>>>>> >>> > >
>>>>>>>>> >>> > >
>>>>>>>>> >>> > >> 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 <mailto:robbin.ehn at oracle.com>
>>>>>>>>> >>> <mailto:robbin.ehn at oracle.com
>>>>>>>>> <mailto: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>
>>>>>>>>> <mailto:robbin.ehn at oracle.com <mailto:robbin.ehn at oracle.com>>
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> <mailto: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,
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 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>>
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> <mailto:robbin.ehn at oracle.com
>>>>>>>>> <mailto:robbin.ehn at oracle.com>
>>>>>>>>> >>> <mailto:robbin.ehn at oracle.com
>>>>>>>>> <mailto:robbin.ehn at oracle.com>>>
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> <mailto:robbin.ehn at oracle.com
>>>>>>>>> <mailto:robbin.ehn at oracle.com>
>>>>>>>>> >>> <mailto:robbin.ehn at oracle.com <mailto:robbin.ehn at oracle.com>>
>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> <mailto: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