On Sun, Apr 10, 2011 at 6:15 PM, Rémi Forax <fo...@univ-mlv.fr> wrote: > I think you can fix a little bit your implementation: > First instead of sending the name of the operation at each call > you should use the indy name to encode that name > instead of pushing it on the stack. > So fixnumFallback should bind the callsite and the indy name.
Yes, I would probably do that eventually, but I'd be surprised if it made a difference here. I just didn't feel like encoding it for the moment. > You should precalculate all your MethodHandle get using > a find(). As far as I know the VM will create a new MH each time. > In PHP.reboot, I store them in different classes (one by operation) > to avoid to initialize too much static variables at start-up. That's a concern for the slow path, but the fast path should be seeing that self instanceof RubyFixnum and going straight to the direct path. I definitely intend to improve this in JRuby's current indy support, since the overhead from bimorphic or worse call sites is *very* high at the moment due to all the handles it recreates. > When you find a MH (in a fast case or in slow case), > you should call it instead of relying on self.callMethod(). Again, should not affect the fast case. Once the first call executes and has bound the direct logic plus a GWT it should always be doing fast path for this case. > Also an interesting thing to test is that in that case you know > the value of the constant (which is a primitive) so instead > of pushing it as argument, you should try to send it as parameter > of the BSM and bind it to your method handle. > I wonder if it's more efficient ? I thought about doing that, but other necessary objects do not get passed to the BSM, like the actual target object, the current JRuby instance, and so on. It's not possible to produce anything other than a dumb, empty CallSite in the BSM without that information. I probably could encode it into a class LiteralFixnumOperatorCallSite < MutableCallSite. Bottom line, though is that the fast path for the indy-based version should be pretty close to identical to the hand-written logic. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
