RFR: improve warmup time for lambda capture

[Sergey Kuksenko]

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.
>>>
>>>
>>>
>>>
>>>
>>>
>>


-- 
Best regards,
Sergey Kuksenko