RFR: JDK-8152690: main thread does not have native thread name
David Holmes
david.holmes at oracle.com
Fri Apr 15 04:32:19 UTC 2016
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