RFR: JDK-8152690: main thread does not have native thread name

[David Holmes]

On 21/04/2016 12:59 AM, Yasumasa Suenaga wrote:
> Hi Kumar,
>
>> Isn't there a management API or something to enumerate the threads ?

Not that shows native thread names.

Existing launcher tests should of course be unaffected by this change.

> On Linux, user apps can get native thread name through
> pthread_getname_np(3).
> However, this function is not called in hotspot and jdk.
>
> So I think it is difficult to get native thread name in all platforms.
>
>
>> Well if it is hard then the jbs must be labelled so, noreg-hard.
>
> I agree to label noreg-hard.

I concur.

Thanks,
David

>
> Thanks,
>
> Yasumasa
>
>
> On 2016/04/20 23:26, Kumar Srinivasan wrote:
>>
>> On 4/20/2016 6:06 AM, David Holmes wrote:
>>> On 20/04/2016 10:58 PM, Kumar Srinivasan wrote:
>>>>
>>>> Hello,
>>>>
>>>> One more thing, what about a launcher regression test ?
>>>
>>> What kind of regression test? I've manually visually inspected the
>>> desired behaviour but a test for it is very problematic. AFAIK there
>>> are no tests for setting the native thread name.
>>
>> Isn't there a management API or something to enumerate the threads ?
>> I am more worried about some seemingly innocuous launcher change
>> causing a regression.
>>
>> Well if it is hard then the jbs must be labelled so, noreg-hard.
>>
>> Kumar
>>
>>>
>>> David
>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>>
>>>>> On 4/19/2016 1:32 PM, David Holmes wrote:
>>>>>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>>   493     /* Set native thread name. */
>>>>>>>   494     SetNativeThreadName(env, "main");
>>>>>>>   495
>>>>>>>   496     /* Invoke main method. */
>>>>>>>   497     (*env)->CallStaticVoidMethod(env, mainClass, mainID,
>>>>>>> mainArgs);
>>>>>>>
>>>>>>> Supposing an exception is thrown in 494 (a very remote case),
>>>>>>> will we not re-enter the VM in 497 with an exception ?
>>>>>>
>>>>>> Yes as I said:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>> Agreed.
>>>>>
>>>>> Kumar
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Kumar
>>>>>>>
>>>>>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote:
>>>>>>>>>
>>>>>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes
>>>>>>>>>> <david.holmes at oracle.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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>>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 ...
>>>>>>>>>
>>>>>>>>> Isn’t there a risk that:
>>>>>>>>>
>>>>>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID,
>>>>>>>>> +                           nameString, JNI_TRUE);
>>>>>>>>>
>>>>>>>>> will raise an exception?
>>>>>>>>>
>>>>>>>>> In the least, shouldn’t we clear any possible pending
>>>>>>>>> exceptions at
>>>>>>>>> the beginning of “SetNativeThreadName“, as you say, but also at
>>>>>>>>> the
>>>>>>>>> very end?
>>>>>>>>
>>>>>>>> I was actually saying at the end, after the call (even though I
>>>>>>>> don't
>>>>>>>> think any exceptions are possible - except for "async"
>>>>>>>> exceptions of
>>>>>>>> course). We shouldn't be able to get to the call with any exception
>>>>>>>> pending as in that case the JNI calls will be returning NULL and we
>>>>>>>> will exit - again this pattern is used extensively in the launcher.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>