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.


More information about the core-libs-dev mailing list