RFR 8062180: MethodHandleImpl.makeArrays throws and swallows java.lang.NoSuchFieldError in normal flow

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Nov 4 21:25:51 UTC 2014

Hi Claes,

On 04.11.2014 23:57, Claes Redestad wrote:
> please review this minor improvement to the initialization of
> MethodHandleImpl$Lazy. Running any code which initializes
> MethodHandlesImpl$Lazy will trigger throwing of
> java.lang.NoSuchFieldErrors, which has a measurable impact on startup.

Do you actually see the impact on startup? I thought the entire MHI$Lazy
thing is here to avoid instantiation on startup. If that is not true,
can you do a proper startup measurement on HelloWorld application?

Here is a handy one-liner:

for S in `seq 1 1000`; do time java Hello; done 2>&1 | grep real | sed
-e "s/0m//g" -e "s/s//g" | awk '{ sum += $2; n++ } END { if (n > 0)
print sum / n; }'

> Additionally, the current lookup via findCollector in varargsArray is
> pointless (and will throw additional java.lang.NoSuchFieldErrors the
> first time a varargsArray of arity > 11 is requested) since all static
> methods which can be found will have been constructed already.
> bug: https://bugs.openjdk.java.net/browse/JDK-8062180
> webrev: http://cr.openjdk.java.net/~redestad/8062180/webrev.00/

Seems rather minor, but every little thing helps startup.

 - Would we be better off asserting (mh == null) instead of breaking and
asserting afterwards?
 - Would we save a few more bytecodes by using the method-local "final
int ARRAYS_COUNT" to handle the magic number, instead of doing a
full-blown field? Ditto for FILL_ARRAYS_COUNT.

> A simple microbenchmark[1] show a very small (~0.5ms) improvement for
> Class.forName("java.lang.invoke.MethodHandleImpl$Lazy")
> Benchmark                               Mode  Samples   Score Score
> error  Units
> o.s.CLBench.loadMethodHandleImplLazy ss      100  46.364       
> 1.740     ms
> o.s.CLBench.loadMethodHandleImplLazy      ss      100 45.440       
> 1.515     ms

Strictly speaking, there is no improvement. Run with more samples to
shrink the error.


More information about the core-libs-dev mailing list