performance issue: 7023639: JSR 292 method handle invocation needs a fast path for compiled code

[John Rose]

On Mar 2, 2011, at 9:42 AM, Charles Oliver Nutter wrote:

> On Tue, Mar 1, 2011 at 6:42 PM, John Rose <john.r.rose at oracle.com> wrote:
>> At least the most important transforms should go through customized code.  These include:
>> - direct access (no transforms)
>> - receiver binding (the bindTo transformation)
>> - trivial asType transformations
>> - invokeGeneric (argument and return value conversions to and from Object)
> 
> Is permute not included here? Given the JVM's ability to allocate
> registers across calls, it seemed like permute would almost become a
> no-op when optimized through.

That is certainly true for invokedynamic, which forces inlining.  For the case of calls to non-constant MHs, the tricky part is to spin the right argument permutation code.  Because there are so many degrees of freedom in permutation space, this leads to a non-trivial classification problem.

For non-constant MHs, I think the important metric is total instructions and memory references over the lifetime of the object, which may be (typically) a construction followed by a few invocations.  If the construction requires spinning a customized invocation adapter for each MH, we lose.  We win if (a) there is a warm-up mechanism on MHs which detects the subset of MHs which are "hot", or (b) there is an internal "function classification" mechanism for caching and reusing equivalent invocation adapters, which can be quickly accessed during MH construction, or perhaps both (a) and (b) together.

> I am currently using permute, insert, drop, and GWT (which of course
> binds three handles that use some combination of the others).

This is helpful information; thanks.

> I expect
> to also use array and field access handles in the future.

BTW, there is a known performance issue with field access handles.  I plan to file a tracking bug for that too.  Should be easy to fix.

> Currently
> only jitted Ruby code uses method handles (via invokedynamic, which as
> you say should inline properly) but as we go forward there's potential
> for the interpreter to use them as well. I suppose that's the case
> you're talking about in this bug...from Java through MH (no indy) to
> some target.

Yes.  And, I intend to level the playing field between MHs and classic interface instances.

-- John