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

[David Holmes]

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