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

[Aleksey Shipilev]

On 11/10/2014 06:13 PM, roger riggs wrote:
> On 11/10/2014 9:54 AM, Aleksey Shipilev wrote:
>> Again, I don't quite understand. Is it about storing the reference to
>> String as the thread name, that can potentially be used for external
>> synchronization?
>>
>> If so, I have a hard time devising a sane test case that might fail with
>> this change. Internal code does not synchronize on Thread.name. Anyone
>> synchronizing on Thread.getName() result has broken synchronization with
>> current code. Anyone synchronizing on Thread.getName() result after this
>> patch will have that (ahem) fixed, plus a performance problem.
>>
>>
> Potentially, any change we make to the implementation can result in
> a change in application behavior, even changing from returning a
> unique String to an immutable but constant String. For 9, this will
> have time to uncover obscure application dependencies.  I'd be more
> cautious about backporting to 8.

Understood. I argue users (futilely) synchronizing on Thread.getName()
are very rare.

-Aleksey.