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