Rémi Forax wrote: > Hi Charlie, > > Charles Oliver Nutter a écrit : >> I've read through Fidgety a few times and I think I'm starting to get it. >> >> So the idea is that you would install a MethodHandle into the call site >> that knows how to handle the incoming objects and (potentially) re-patch >> the call site with a new method? >> > I don't think that it is possible to re-patch without subclassing > JavaMethodHandle. > But you can use more than one subclasses of JavaMethodHandle. > > You can also store info in subclass of CallSite.
I think I understand this now...see my more recent mail. >> Is there any guarantee that the code in the MethodHandle will be inlined >> through? > Currently, this garantee doesn't exist. > But the idea is that all (or most of ) method handles will to be > optimized especially. > > Some method handles are already optimized because corresponding > fast path already exists in the VM. I'm curious if custom method handles, as shown in Fidgety, will "get out of the way" when inlining happens. If the "Guard" class there prevents inlining the resulting invocations, it may be no better than what I have now. >> I may have missed some discussion on this, but I want to be >> absolutely clear on this point. If I wire up things exactly as in >> Fidgety's "Guard" method handle, will (e.g.) Hotspot inline all the way >> through? What are the edge cases? >> > Hotspot will inline like usually. I suppose this is where I have some concern. Right now, as evidenced by Cliff Click's exploration, our generalized "CachingCallSite" class completely breaks inlining of target dynamic methods into the caller. I have modified JRuby recently to allow lifting the target method object all the way back to the original call location, but it ultimately results in a *lot* more bytecode. My hope is that by having the path from my code's call site to a target method object be only via MethodHandle subtypes, there will be no impedance of inlining that target. > Charlie, > just remember that you will run a prototype not a full featured race car :) I'm just trying to understand the end goal :) If this is expected to be the optimal way to wire things together, I will proceed happily. > Hint: I think your JRuby internals should run on bootstrap classpath, > the current prototype has some classloading problems. I may have run into this...the class in which the bootstrap method lies can't be used as an argument to any dynamic invocations using that bootstrap, yes? This should not prevent me from proceeding. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
