> On 17 Jan 2017, at 08:06, Claes Redestad <claes.redes...@oracle.com> wrote: > > Hi, > > as a follow-up to JDK-8086045, further analysis has found a number of small, > simple improvements that can be made to further improve startup > characteristics of typical usage of java.lang.invoke: > > - CallSite::<clinit> looks up two MethodHandles that aren't used in many > typical applications and should be lazily constructed > - CallSite.CONTEXT_OFFSET is calculated but never used > - The ConcurrentHashMap in MethodType$ConcurrentWeakInternSet is resized > multiple times even for relatively trivial tests, and initializing it to a > larger size is footprint neutral but beneficial to startup to many > applications > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172905 > Webrev: http://cr.openjdk.java.net/~redestad/8172905/webrev.01/ > > This small set of relatively non-intrusive changes has a measurable impact to > startup - generates fewer classes on some tests, does less work on all - > which partially help with a number of startup regressions tracked in 9 due to > heavier and earlier use of j.l.invoke. >
Look ok. It’s either place the static finals in separate nested classes, or use @Stable on non-final statics with lazy initialization in methods (with the possibility of multiple invocations when concurrently executing). Nested classes seems fine here. Paul.
