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

[Kumar Srinivasan]

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 ?

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
>>