On Aug 15, 2011, at 3:19 PM, Charles Oliver Nutter wrote: > 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?
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. Exactly. tom > >>> 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
