RFR [10]: 8186517: sun.nio.cs.StandardCharsets$Aliases and ClassMap can be lazily loaded

[Claes Redestad]

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.

Agreed.

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

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

/Claes

>
>
> On Mon, Aug 21, 2017 at 6:46 AM, Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi,
>
>     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/
>     <http://cr.openjdk.java.net/%7Eredestad/8186517/jdk.00/>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8186517
>     <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.
>
>     /Claes
>
>