RFR: JDK-8154331: main thread should be treated as JNI-attached thread.

[Yasumasa Suenaga]

Hi David,

> This issue does introduce an incompatible change in behaviour so it may be
> best to defer this part until Java 10, as Dan suggested in the bug report.

Okay,
If I cannot get sponsor and reviewer, I will come back on this issue after
jdk 10 repos is opened.


Thanks,

Yasumasa


On 2016/04/17 7:25, David Holmes wrote:
> On 16/04/2016 10:03 PM, Yasumasa Suenaga wrote:
>> Hi David,
>>
>>> Correcting this behaviour could be seen as
>>> a regression because there would no be no way to set the native name of
>>> the main thread.
>>
>> If my proposal in JDK-8152690 [1] is merged, Java developer can change native
>> thread name with reflection.
> 
> Yes though access control may get in the way.
> 
>> IMHO, we can merge changes for jvm.cpp and Thread.{c,java} to this issue
>> from JDK-8152690.
> 
> Not sure what you mean. I want to keep the two issues distinct. This
> issue does introduce an incompatible change in behaviour so it may be
> best to defer this part until Java 10, as Dan suggested in the bug report.
> 
> Thanks,
> David
> 
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040276.html
>>
>>
>> On 2016/04/16 16:25, David Holmes wrote:
>>> Hi Yasumasa,
>>>
>>> On 15/04/2016 11:23 PM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> In discussion about JDK-8152690 [1], we were found a bug.
>>>> Java main thread which is started by Java launcher is not treated as JNI-attached thread.
>>>>
>>>> I uploaded a webrev.
>>>> Could you review it?
>>>>
>>>>       http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/
>>>>
>>>> I cannot access JPRT.
>>>> So I need a sponsor.
>>>
>>> As I just wrote in the bug report:
>>>
>>> I think it was an oversight that when the OSX port brought this code in,
>>> the main thread was not marked as being a JNI-attached thread - as
>>> suggested by this comment:
>>>
>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and
>>> JNI attached threads
>>>
>>> However because of this oversight a call to Thread.setName from the main
>>> thread would** cause the native thread name to be set (normally we don't
>>> modify JNI-attached threads). Correcting this behaviour could be seen as
>>> a regression because there would no be no way to set the native name of
>>> the main thread.
>>>
>>> Given that we don't actually gain anything by "fixing" this I'm inclined
>>> to simply leave it as-is.
>>>
>>> ** I haven't actually verified this as I don't have access to a system I
>>> can check it on right now. But based on code inspection this appears to
>>> be the case.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html
>>>>