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