Hi David,
unless my reading of JEP 334 (and JEP 303) is completely off then custom
constants (say, Attributes$Name) would effectively be turned into
condys, implying a bootstrap method call for them to be constructed. So
would carry similar construction overhead as the current implementation.
And even if I'm missing some detail of JEP 334 that would allow these
Name objects to be loaded in without any runtime BSM call overhead
whatsoever, we'd still need to create the KNOWN_NAMES Map of these
things. So maybe create the entire map as a constant? I'm not sure we
even could describe something like a Map<String, Name> as a loadable
constant, but it'd be an interesting prospect... still, I believe the
creation cost would end up similar to the status quo.
So: while they may share some common goals (move computation out of
runtime), I think there are some things heap archiving will keep doing
better. Facilitating better sharing between JVMs is another benefit that
comes from more extensive heap archiving.
/Claes
On 2018-12-04 06:09, David Holmes wrote:i
Hi Claes,
Meta-comment: are these Names candidates for the forthcoming
compile-time evaluation of constants? Just wondering if these
optimizations (and even the archiving itself) will be moot in the future?
vev
Thanks,
David
On 4/12/2018 2:02 am, Claes Redestad wrote:
Hi,
initializing java.util.jar.Attributes.Name.<clinit> executes ~20k
bytecodes setting up and eagerly calculating case-insensitive hash
codes for a slew of Name objects.
By archiving the resulting set of Names and initializing public
constants from the archived map, we reduce time spent starting up
(Name.<clinit> drops to 368 executed bytecodes) and improve the
footprint sharing effect of using CDS:
http://cr.openjdk.java.net/~redestad/8214712/jdk.00/
Testing: tier1-2 running
Verified a 1-2.5ms startup improvement on java -jar Hello.jar
- significant and stable reduction in instruction count, branches and
branch misses
- only adds ~1.1Kb to the dumped CDS archive
Thanks!
/Claes
