Trying to work newer indy into JRuby

[Charles Oliver Nutter]

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