RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance
Aleksey Shipilev
aleksey.shipilev at oracle.com
Wed Sep 11 17:05:12 UTC 2013
On 09/11/2013 08:53 PM, Sergey Kuksenko wrote:
>> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>
>> * webrev metadata: "invokation" -> "invocation"
> misprint. Should I fix it right now, or may it be done later?
I think later is good. Don't propagate that typo into the final
changset, that what I meant.
>> * Why $caller is MethodHandles.Lookup now? Is it known to have that type?
> Yes.
> MethodHandles.Lookup is return type of IMPL_LOOKUP.in()
I see, OK then.
>> * I would put the entire LMF.metafactory call inside the new method.
>> That way, instanceof checks are right before the (otherwise potentially
>> unsafe) casts.
>
> At that case the single method should return two values: boolean flag
> success/failure and CallSite.
Is "null" already reserved as the return value for metafactory? What
bothers me is that I need to scroll down to figure out the arguments are
indeed checked before you do the casts.
>>> The modification gives +10% - +35% to lambda linkage performance
>>> (depends on amount of lambdas).
>>
>> Any JSR292/Nashorn benchmarks to prove it does not degrade the "usual"
>> bootstrap scenarios? I understand most of the performance is dominated
>> by already-linked sites, but still.
>
> I check it on octane - no perf difference. But I need somebody to
> recheck my measurements.
Good. That is good enough for me.
-Aleksey.
More information about the core-libs-dev
mailing list