RFR: JDK-8152690: main thread does not have native thread name
Kumar Srinivasan
kumar.x.srinivasan at oracle.com
Wed Apr 20 12:58:34 UTC 2016
Hello,
One more thing, what about a launcher regression test ?
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
>>>>>
>>>
>
More information about the core-libs-dev
mailing list