JRuby invokedynamic updates

[Tom Rodriguez]

On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:

> 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?

It really only to deal with pathologically long chains.  Most method handle chains are pretty simple and should generally just be inlined.  However I could build a chain that included a very large number of calls embedded in it and blindly inlining that could cause the compile to grow too large.  Chains of method handle chains make it worse.  Whatever limit we would pick would be fairly high so that no normal usage would never be cut off.

> 
> 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).

Client will start to do more inlining in 7u2 but it will still be limited because of the lack of profiling.  Being able to compile them separately would make the whole system more stable performance wise.  I don't know that we can do that for 7u2 though.  Doing it correctly may require more machinery than we have time to build for 7u2.

tom

> 
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev