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

[David Holmes]

On 10/11/2014 9:52 PM, Chris Hegarty wrote:
> Aleksey,
>
> 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 String construction is a bottleneck just cache it.

David
-----

> Trivially, after your changes will NPE be thrown if setName(null), as it
> is today ?
>
> -Chris.
>
> On 09/11/14 18:45, Aleksey Shipilev wrote:
>> Hi,
>>
>> Thread.getName() returns String, and does new String instantiation every
>> time, because the thread name is stored in char[]. Even though we use a
>> private String constructor that shares the char[] array without copying
>> it, this still hurts some use cases (think extra-fast logging). To the
>> extent some people actually maintain Map<Thread, String> to avoid it.
>>   https://bugs.openjdk.java.net/browse/JDK-8059677
>>
>> Here's the attempt to maintain String instead of char[]:
>>   http://cr.openjdk.java.net/~shade/8059677/webrev.01.jdk/
>>   http://cr.openjdk.java.net/~shade/8059677/webrev.01.hs/
>>
>> JDK changes are trivial, but HS changes require some rewiring, since VM
>> treats Thread.name specially. However, it turns out we can make a
>> contained change, since the getter is used sparingly, and setter seems
>> to be not used at all. Any trouble with this change?
>>
>> Testing: JPRT, manual tests, jdk/test/java/lang/Thread jtreg,
>> hotspot/test/runtime/ jtreg, vm.quick.testlist, nsk.jvmti.testlist,
>> svc.quick.testlist
>>
>> Thanks,
>> -Aleksey.
>>