JRuby invokedynamic updates

[Charles Oliver Nutter]

On Fri, Aug 12, 2011 at 1:18 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> I wonder if we need to be slightly more selective than this.  Most method handle chains are relatively small and we shouldn't be penalized for that but they could be arbitrarily large too.  Worst case they just expand into a bunch of call sites I guess so maybe it's not that bad.  Maybe we need an alternate metric for this, like number of call sites in the method handle adapter?

Well, let me play devil's advocate here: why not just discount MH
chains completely?

I've been treating method handles as a way to communicate intent
directly to the JVM. Method handles are like JVM IR...and I'd like to
see them unhindered by limits designed around JVM bytecode.

What's the problem with having them discounted en masse?

> This wouldn't be so bad if method handle chains could be compiled separately.  I suspect we're going to have to support that eventually.  Doing that would make the performance cliff much smaller I think.

This probably needs to happen for client mode at the very least. We
probably can't get client to inline invokedynamic, but if it at least
dispatches to a compiled MH chain it would be a lot better than what
it does now (which I think is just execute the chain of handles
as-is...usually very slow).

- Charlie