On Wed, Nov 30, 2011 at 9:52 PM, Stephen Bannasch <stephen.banna...@deanbrook.org> wrote: > At 3:03 PM -0500 11/30/11, Stephen Bannasch wrote: >>Benchmark code here: https://gist.github.com/1410423 > > The hpricot benchmark is also slowed down consdierably.
I have found more issues in my invokedynamic binding logic and am in the process of repairing them. I've pushed a couple changes to master...can you re-test? Here's updated REXML benchmark numbers. *Parsing small document for 5 seconds ... 3687 calls (737.40/s) Adding new elemnt for 5 seconds ... 583686 calls (116737.20/s) Document creation for 5 seconds ... 118806 calls (23761.20/s) Writing tree for 5 seconds ... 8299 calls (1659.80/s) By-hand search for 5 seconds ... 417629 calls (83525.80/s) XPath search for 5 seconds ... 1327 calls (265.40/s) *Parse large document for 5 seconds ... 337 calls (67.40/s) Stream parsing for 5 seconds ... 590 calls (118.00/s) *Pull parsing for 5 seconds ... 534 calls (106.80/s) *SAX2 parsing for 5 seconds ... 170 calls (34.00/s) *Lightweight parsing for 5 seconds ... 726 calls (145.20/s) The starred benchmarks are still slower than non-invokedynamic, but the others are all faster...in some cases quite a bit faster. I'm investigating the remaining anomalies...profiles don't look right, especially on the initial "small" parse. The five benchmarks at the bottom may be ok...they seem to vary wildly regardless of invokedynamic, so they're probably at least on par. I am *very* glad you brought this to my attention :) The logic I was using to build a PIC and to completely invalidate call sites had a critical flaw: if a PIC was built and one of those classes were subsequently modified, the call site would get into a state where it was repeatedly rebound each time those types were re-encountered. This caused several heavily-hit call sites in the benchmark to rebind the call site on nearly every invocation, which caused much of the performance issues. I am still seeing rebinding in profiles of some of the remaining slow benchmarks, so I'm missing something. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
