RFR: JDK-8152690: main thread does not have native thread name
Yasumasa Suenaga
yasuenag at gmail.com
Sat Apr 23 13:24:38 UTC 2016
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