RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap

[Martin Buchholz]

Thanks, Claes.

I like very much how you've been reducing java startup every release, but
...
I'm bothered by the small but eternal overhead of the INSTANCE fields ...
It looks like the UTF_16* charsets don't need INSTANCE fields since they
will not be referenced anywhere else in java.base - can we at least get rid
of those, despite the asymmetry?

A heroic optimization would be to create a StandardCharsets with only the 3
special fields and then somehow retransform the class to add some more
final static fields after phase1 is over (but I have no idea what it would
take).

On Mon, Apr 9, 2018 at 6:45 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> JDK-8200310 cleaned up java.nio.charset.StandardCharsets to not use
> Charset.forName, but also removed the optimization to have unconditionally
> loaded charsets set up static INSTANCE constants, which means that many
> systems the java.nio.charset.StandardCharsets will be initialized in
> System.initPhase1.
>
> This should be avoided since at this point the VM is just booting up and
> any code executed delays initialization of JIT etc.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8201179/open.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201179
>
> This patch makes all the constants in j.n.c.StandardCharsets use new
> INSTANCE fields of each respective Charset and adds some comments as to why
> they exist.
>
> I also think we should avoid depending on j.n.c.StandardCharsets within
> java.base as to not accidentally execute more code in initPhase1 than
> absolutely necessary, so I've changed uses in core packages (java.lang,
> java.util, java.zip...) to use the internal alternative.
>
> Thanks!
>
> /Claes
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180409/e39be0b8/attachment.html>