Trying to work newer indy into JRuby
Charles Oliver Nutter
charles.nutter at sun.com
Mon May 18 03:28:59 PDT 2009
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
> 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
> 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
>> 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.
> 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.
More information about the mlvm-dev