On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez <tom.rodrig...@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? * 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@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
