On Mar 22, 2012, at 11:39 AM, Charles Oliver Nutter wrote: > Hey all! We're nearing the end of JRuby's 1.7 dev cycle, and I thought > I should check in on the status of invokedynamic optimization work, > update releases, and so on. > > We've been getting more and more excellent reports of JRuby > performance far exceeding people's expectations. A number of folks are > already running JRuby 1.7dev in production because "it's the fastest > thing they've ever seen". Kudos for all the excellent work up to this > point!
That's good news. > > Of course, nothing's ever perfect :) > > Here's a few outstanding items I know have been in progress, but we > haven't heard about recently. > > * indy classloading headaches > > The old NoClassDefFound problems seem to have gone away (or I just > haven't been able to trigger them) but more recently I reported on > this list about LinkageErrors that seemed to be caused by indy. I > eventually patched around them, forcing more classes to be created and > isolated...but I don't see how I could have been at fault in my code. This should all disappear in our new implementation (meth-lazy patches in the repository) because of the way we handle signatures. Unfortunately the compiler support isn't complete yet (inlining is not perfect yet) so it may be a pain to test it (because it's slow) but the code executed in the interpreter and in the compilers is the same. And so should trigger the same errors (if there are any). > > * degraded performance is still a big issue > > I've run into a number of user cases where large methods end up > significantly slower with indy than without. The performance of > degraded (read: not jitted or not inlined) call sites and MH chains is > so bad that some cases end up worse than JRuby's interpreted mode. I > talked with Christian some weeks ago about a new plan to always > compile the MH chain and do be smarter about what gets inlined into > it, but I have not heard anything nor tracked progress since then. > > The performance is bad enough that I may have to install some tiering > logic into JRuby's compiler so that methods over a certain size don't > use invokedynamic at all. It will be messy. That performance problem also disappears with the meth-lazy stuff. > > * u4? u6? > > If I remember right, the original plan was to have the first big round > of optimizations in u2, and then the "right way" of optimizing along > with stability issues fixed for u4. With u4 rapidly locking down (did > I see something about phase 2?) where do we stand on getting indy > updates into that release? 7u4 is pretty much closed. The newer stuff has to wait for a future update release. > > As always, I'm standing by to help test, benchmark, profile, and read > assembly dumps. I've not *yet* had a change to start working on > Hotspot itself, but there may be some interesting changes coming up > that will make it easier for me to do so :) I try to polish the meth-lazy.jit patch a bit so that it works and running tests isn't awfully slow. Let's see what I can come up with. I'll keep you posted. -- Chris > > Anyway, thanks for everything, and I hope indy work is still moving > forward. It really is amazing. > > OH, P.S. I'm delivering a keynote at JAXConf 2012 on invokedynamic! > I'd love to get as much information as possible about current and > future status of indy in OpenJDK. > > - 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
