Hi, Looks good.
LambdaForm.java -- 851 MethodType invokerType = methodType(); 852 assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType)); … 1183 assert(checkArgumentTypes(arguments, methodType())); … 1201 assert(checkArgumentTypes(arguments, methodType())); I am always wary of removing asserts, do you think these are redundant? — From this and the last fixes how much have you cut from the start up time? Paul. > On 10 Apr 2017, at 08:37, Claes Redestad <[email protected]> wrote: > > Hi, > > another startup optimization for java.lang.invoke, this one collecting a set > of small fixes I've been wanting to get done for a while, including: > > - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor > - trusted MethodType lookups could be promoted without constructing new > objects > - InvokerBytecodeGenerator: creation of className and sourceFile can be done > lazily, which reduces String allocations in those cases where there's a > pre-generated form to be found > - MethodType lookup done twice when looking up pregenerated members (oops!) > - A lot of vararg array creation during startup in various places. A larger > rewrite could be warranted, but we can some startup gain by simply > constant-izing oft-used constant arguments such as MethodType.invokerType > > Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8178387 > > Test: java.lang.invoke jtreg tests, verified each change in this patch (and > JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap. > > Thanks! > > /Claes
