RFR: JDK-8152690: main thread does not have native thread name
Yasumasa Suenaga
yasuenag at gmail.com
Tue Apr 26 09:22:52 UTC 2016
Hi David,
> 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
Thanks, I understood.
>>> 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.)
I think we can call uncaught exception handler before calling DestroyJavaVM().
I added it in new webrev for jdk:
http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/
http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/
DispatchUncaughtException() in java.c emulates uncaught exception handler
call in JavaThread::exit().
I think this patch can provide the solution for our issue.
Could you check it?
Thanks,
Yasumasa
On 2016/04/26 14:16, David Holmes wrote:
> 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