JRuby invokedynamic updates
tom.rodriguez at oracle.com
Mon Aug 15 15:26:25 PDT 2011
On Aug 15, 2011, at 3:19 PM, Charles Oliver Nutter wrote:
> On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>>> 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'm not a compiler guy, so I don't know what "too large" means when it
> comes to the compile. Is it:
> * Too complex graph so compilation runs too long?
> * Too big native code so something blows up or crashes?
These two mostly.
> * Too big native code so it doesn't fit in cache and runs much slower?
> As long as the limit is suitably high, I think everyone will be happy.
> I can't see any JRuby use involving more than a few dozen adapters for
> the most complex cases, mostly argument juggling and converting.
>>> 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.
> My contingency plan is to only turn on invokedynamic when I can see
> we're running on Hotspot C2, and use the old mechanisms when running
> under C1. That is an acceptable trade-off until client mode handles
> invokedynamic/MHs better than it does now.
> - Charlie
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev