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

Chris Hegarty chris.hegarty at oracle.com
Mon Nov 10 13:53:24 UTC 2014

On 10/11/14 12:56, David Holmes wrote:
> 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 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.


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

More information about the core-libs-dev mailing list