RFR: 8198755: Reduce cost of InvokerBytecodeGenerator::isStaticallyInvocable/-Nameable

John Rose john.r.rose at oracle.com
Tue Feb 27 16:53:15 UTC 2018


Looks good.

On Feb 27, 2018, at 8:42 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
> 
>> On Feb 27, 2018, at 7:42 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>> 
>> Hi,
>> 
>> when generating LF classes with InvokerBytecodeGenerator, almost 5% of executed code is concerned with determining if members and parameters are statically invocable and/or nameable, which we can assert is always true for MethodHandle arguments.
>> 
> 
> IIRC this is for the case where we can reliably crack open the method handle (from it’s member name) and invoke it directly?

Yes, invoked directly from inside LF code in java.lang.invoke.

The 'member' parameter already gives evidence that somebody
has gotten the right to call the method indirectly via a MH,
and the LF generator wants to lower that to a direct invocation
at bytecode level.

That's why MH package-private members are called directly.

> 
>> Since MethodHandle targets and parameters are common, it's a profitable startup optimization to add a fast-path test for this.
>> 
>> Webrev: http://cr.openjdk.java.net/~redestad/8198755/jdk.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198755
>> 
> 
> 
> 957         for (int i = 0; i < mtype.parameterCount(); i++)
> 958             if (!isStaticallyNameable(mtype.parameterType(i)))
> 
> Revert back to: 
> 
>         for (Class<?> ptype : mtype.parameterArray())
>              if (!isStaticallyNameable(ptype))
> 
> ?

+1

— John


More information about the core-libs-dev mailing list