RFR (S) 8059677: Thread.getName() instantiates Strings

[Staffan Larsen]

> On 10 nov 2014, at 15:55, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Hi Staffan,
> 
> Ow, it seems very like it.
> So, what testlist have I missed to catch this?

Probably vm.tmtools.testlist and/or nsk.sajdi.testlist. Just a warning that these tests are far from stable. Sorry about that.

/Staffan

> 
> -Aleksey.
> 
> On 11/10/2014 05:51 PM, Staffan Larsen wrote:
>> I’m afraid this change requires changes in the Serviceability Agent as well. See OopUtilities.threadOopGetName() for example.
>> 
>> /Staffan
>> 
>>> On 10 nov 2014, at 15:19, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>> 
>>> Hi David, Chris,
>>> 
>>> On 11/10/2014 04:53 PM, Chris Hegarty wrote:
>>>> On 10/11/14 12:56, David Holmes wrote:
>>>>> On 10/11/2014 9:52 PM, Chris Hegarty wrote:
>>>>>> I have only looked at the libraries changes, and I think they make sense
>>>>>> . As in, I can find no reason why the name cannot be changed to be a
>>>>>> String.
>>>>> 
>>>>> Very quick response, but IIRC this has been examined in the past and
>>>>> there were reasons why it can't/shouldn't be done. Will try to dig out
>>>>> more details in the morning.
>>>> 
>>>> If there was previous discussion on this, that revealed some substantial
>>>> issue, that would be great, but I can't recall, or find, it now.
>>>> 
>>>> Hotspot express, and the desire for hotspot to run with different
>>>> library versions, would certainly cause complication, but I don't
>>>> believe that is an issue now.
>>>> 
>>>> Just on that, the library changes are minimal, and if this were to
>>>> proceed then they can accompany the hotspot change, as they make their
>>>> way into jdk9/dev.
>>>> 
>>>> Anyway, this should await your reply.
>>> 
>>> Alan was having the same concern, there is an issue with JNI/JVMTI and
>>> other power users that might break when exposed to under-constructed
>>> Thread, e.g:
>>> https://bugs.openjdk.java.net/browse/JDK-6412693
>>> 
>>> This is why I ran jvmti and serviceability tests for this change,
>>> yielding no failures. This reinforces my belief this patch does not
>>> break the important invariant: if there is a problem with "Thread.name =
>>> name.toCharArray()" anywhere in Thread code, then "Thread.name = name"
>>> does neither regress it further nor fixes it.
>>> 
>>> Then I speculated that having char[] name would help VM initialize the
>>> name if we wanted to switch to complete VM-side initialization of
>>> Thread, but it seems we can do String oop instantiation in the similar vein.
>>> 
>>> Caching the name feels like a band-aid, that will probably complicate
>>> the Thread initialization on VM side even more. Let's wait and see if
>>> David can come up with some horror issue we are overlooking. :)
>>> 
>>> Thanks,
>>> -Aleksey.
>>> 
>> 
> 
>