RFR: 8201179: Regression due loading java.nio.charset.StandardCharsets during bootstrap
martinrb at google.com
Mon Apr 9 16:47:26 UTC 2018
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
On Mon, Apr 9, 2018 at 6:45 AM, Claes Redestad <claes.redestad at oracle.com>
> 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
> 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.
More information about the core-libs-dev