RFR: improve warmup time for lambda capture

[Sergey Kuksenko]

On 08/22/2013 08:33 PM, Brian Goetz wrote:
> 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?
it is statistically insignificant difference. Performance difference
after warmup is withing run-to-run variance. So we may don't care about
this.

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


-- 
Best regards,
Sergey Kuksenko