RFR : 8186517: sun.nio.cs.StandardCharsets$Aliases and ClassMap can be lazily loaded
claes.redestad at oracle.com
Mon Aug 21 18:53:48 UTC 2017
On 2017-08-21 20:05, Martin Buchholz wrote:
> I agree we should optimize for common charset names, in part to help
> the world move to UTF-8.
> It's *weird* to canonicalize to lower case, when the canonical charset
> names are all uppercase ("UTF-8" instead of "utf-8").
A pre-existing weirdness, and it goes deep enough that I haven't dared
> 62 public static final String UTF_8 = "UTF-8";
> Is this still used?
> Maybe the very first thing lookup() should do is check
> charsetName == UTF_8
Subsequent lookups are very likely to hit the two-element cache in
Charset, so I've not seen this add up.
> Is switching from char to StringBuilder really an improvement?
> Charset names are all short, so the cost of copying the char to a
> byte is negligible.
This allows us to not load and touch the code to deflate a char to a
byte (StringUTF16), so a tiny, tiny startup win. Throughput-wise it's
likely no different.
> On Mon, Aug 21, 2017 at 6:46 AM, Claes Redestad
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
> the Aliases and Classes inner classes in StandardCharsets can be
> lazily-loaded by restructuring how we check for the three
> default-loaded charsets. This removes some classloading and
> work from happening during critical phases of the VM startup,
> as well as a net gain on any systems that default to any of the
> three standard charsets (UTF-8, Latin-1, ASCII).
> Webrev: http://cr.openjdk.java.net/~redestad/8186517/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186517
> I'm not sure if the pre-existing optimization to allow
> StandardCharsets.charsets() unsynchronized access to internals
> is really necessary (or even 100% correct), but by ensuring we
> retrieve the Aliases and Classes instances in a synchronized block
> we should be no worse off semantically here.
More information about the nio-dev