JDK-8059677 : Thread.getName() instantiates Strings
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 8u20,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-10-03
  • Updated: 2016-07-21
  • Resolved: 2014-11-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u102Fixed 9 b42Fixed
Related Reports
Relates :  
JDK-4745629 - (thread) Thread.setName does needless string allocations (don't use char[])
Description
"Reported" here: https://twitter.com/VladimirSitnikv/status/518043826678956033

We can just store the String as Thread.name, can't we?
Are there initialization races? Security implications?
Comments
Update: http://cr.openjdk.java.net/~shade/8059677/webrev.03.jdk/ http://cr.openjdk.java.net/~shade/8059677/webrev.03.hs/ Changesets: http://cr.openjdk.java.net/~shade/8059677/8059677-jdk.changeset http://cr.openjdk.java.net/~shade/8059677/8059677-hs.changeset
12-11-2014
Update: http://cr.openjdk.java.net/~shade/8059677/webrev.02.hs/ http://cr.openjdk.java.net/~shade/8059677/webrev.02.jdk/ RFR: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029610.html
11-11-2014
RFR: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029569.html
09-11-2014
First working patch: http://cr.openjdk.java.net/~shade/8059677/webrev.01.hs/ http://cr.openjdk.java.net/~shade/8059677/webrev.01.jdk/ Passes JPRT, jdk/test/java/lang/Thread and hotspot/test/runtime/ jtreg tests.
09-11-2014
Yes, it was the usage in the VM that meant it has to stay as a char[] the last time.
04-10-2014
Okay, the pending trouble is that Thread.name field is treated by VM (see javaClasses.cpp), and some VM changes are required to communicate the changed layout to VM itself.
03-10-2014