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

[Aleksey Shipilev]

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.