RFR: improve warmup time for lambda capture

Brian Goetz brian.goetz at oracle.com
Wed Aug 21 10:09:57 PDT 2013

In the generateFactory() method, you use ALOAD to push the arguments on 
the stack for the call to the constructor.  But, shouldn't you use the 
same trick used elsewhere:

   ctor.visitVarInsn(argTypes[i].getOpcode(ILOAD), i);

to generate different sort of LOAD (ILOAD, etc) if the arguments are not 

On 8/21/2013 12:41 PM, Sergey Kuksenko wrote:
> Hi,
> Please review the webrev at:
> http://cr.openjdk.java.net/~skuksenko/jsr335/static_factory/webrev.00/
> Also I need a sponsor to commit.
>     The issue with lambda capture warmup is related to current jsr292
> implementation.
>     Lambda metafactory creates call site which points to (MethodHandle)
> lambda generated class constructor. Invocation of the constructor is
> performed via some generated call chain (jsr292 implementation
> specific). When C1 or C2 compiles it - all these methods are inlined and
> code is clean, but interpretation is relatively slow. Such jsr292 call
> chain for static methods (MH to static method) is simpler than to
> constructor that is why it is warmed up faster.
> The patch generated static factory method for lambda capture in each
> generated class and links CallSite to the static factory method.
>     Attached charts shows warmup improvement (both tiered and non-tiered
> compilation). The benchmark creates 4000 different lambdas, each lambda
> captures one variable.
>    Of course this improvement is implementation specific and depends on
> jsr292 implementation. In future (when/if jsr292 will warmup MH to
> constructor with the same speed as MH to static method) we may revert it
> back.

More information about the lambda-dev mailing list