On Wed, Aug 5, 2009 at 7:30 PM, Rémi Forax<fo...@univ-mlv.fr> wrote: > I have seen some small rooms of improvement in the JRuby code > (apart from replacing DynamicMethod by MethodHandle which is > what must be done but which is also in my opinion a more than one week job > :)
Nah, it's a day at most. Here's the process: 1. When generating DynamicMethods that point at real Java code, also attach target class, method name, and signature info. 2. Use this info at runtime when preparing the call sites. And even if we went with a stupid-simple solution, I could switch on JRuby's reflection-based mode and simply unreflect the Method object each ReflectedMethod (extends DynamicMethod) would contain. The fact that we can juggle handle information immediately before installing it in the call site makes everything pretty easy. And here's a couple questions for you and John: 1. If we desired to expand JRuby's monomorphic inline caching in indy mode, could we simply chain together a series of GWTs that perform type comparisons? So we'd have something like at call site:GWT1 test: is receiver a String target: call cached String method fallback: GWT2 test: is receiver an Array target: call cached Array method fallback: GWT3 ... fallback: slow lookup and perhaps add to or edit the GWT chain based on some heuristic Since the entire sequence would still inline (ideally) it would be similar to the regenerated call site logic that the DLR does...except way better, because it wouldn't interfere with the eventual targets inlining into the caller. 2. Have you (or anyone else) thought much about how indy might eventually play with the tiered compiler? I could see the two working extremely well together. In my head, the first tier compilation would happen quickly and know about method handle chains, but also install appropriate profiling hooks that can gather information about those chains. For example, in the GWT case above, it would include branch profiling to see which of the types in the PIC were getting hit most often. Then the second tier compiler could do a better job of optimizing those paths. I know the tiered compiler work has slowed over the past few months, but I've also heard plans are still to make it a reality. Tiered compilation combined with indy would certainly be worth more than the sum of its parts, since dynamic, multi-stage optimization is the name of the game for fast dynamic languages. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev