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

[Paul Sandoz]

> On 10 Apr 2017, at 10:31, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> 
> On 2017-04-10 18:48, Paul Sandoz wrote:
>> Hi,
>> 
>> Looks good.
> 
> Thanks!
> 
>> 
>> LambdaForm.java
>> --
>> 
>>  851         MethodType invokerType = methodType();
>>  852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));
> 
> This one was accidentally removed, will put it back (without the local invokerType var).
> 

Ok.


>> 
>> …
>> 
>> 1183             assert(checkArgumentTypes(arguments, methodType()));
>> 
>> …
>> 
>> 1201                 assert(checkArgumentTypes(arguments, methodType()));
> 
> The checkArgumentTypes method has been shortcutted for quite some time (if (true) return true;),
> so the asserts aren't doing anything but making -Xcomp tests run slower and emit a lot of warnings
> in my IDE.
> 

Ok.


>> 
>> 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?
> 
> Don't expect too much! These two add up to about ~60k fewer bytecode executed to bootstrap j.l.invoke
> and run a trivial lambda, which is about 13% of the total and shows up as around or somewhat less than a
> millisecond improvement on my machine (out of the ~19-20ms it now takes to bootstrap and execute the
> first lambda on my machine).
> 

Keep chipping away, every bit helps :-)

Separately, i am curious how much GC activity occurs at startup before the main method is called. Would it be possible to overlay hotspot activity on the Java flame graph?

Paul.