RFR: improve warmup time for lambda capture

[Esko Luontola]

The following code does fails to handle primitive types. The xLOAD 
opcode depends on the type of the argument. Also long and double require 
the index to be incremented by two instead of one.

+        for (int i = 0; i < argTypes.length; i++) {
+            m.visitVarInsn(ALOAD, i);
+        }

Here is an example of a proper way to generate that code:

https://github.com/orfjackal/retrolambda/blob/411579c012cd153351470fd5a828348c6bd99eb2/retrolambda/src/main/java/net/orfjackal/retrolambda/LambdaClassBackporter.java#L96-L100


Sergey Kuksenko wrote on 21.8.2013 19:41:
> 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.
>
>
>
>
>
>

-- 
Esko Luontola
www.orfjackal.net