[10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities

[Paul Sandoz]

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 <claes.redestad at oracle.com> 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