RFR: improve warmup time for lambda capture

[Brian Goetz]

Reviewed!

Tested with the usual lambda tests, all pass.

Would like to get one more review from Robert.

I notice from the graphs that the time-to-performance is much better, 
but the asymptotic performance is slightly worse.  Hard to tell from the 
graph just how big that number is -- can you clarify the long-term hit?

On 8/22/2013 9:04 AM, Sergey Kuksenko wrote:
> Fixed!
>
> Here is new webrev:
>
> http://cr.openjdk.java.net/~skuksenko/jsr335/static_factory/webrev.01/
>
>
> On 08/21/2013 09:30 PM, Brian Goetz wrote:
>> Or, for a more proximate example, look about 20 lines down in the same
>> file, in the "generateConstructor()" method :)
>>
>> On 8/21/2013 1:17 PM, Esko Luontola wrote:
>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>