Trying to work newer indy into JRuby

[Rémi Forax]

Charles Oliver Nutter a écrit :
> 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 don't think that the guard class can prevent inlining, if the method 
of the guard class is reasonable
i.e if it contains few checks and corresponding branches.

About your cache, your cache need to be written in term of MethodHandles.
You should not use a big fat generic cache that used boxing and array 
wrapping.

Pratically, let's take the example of an inline cache,
your guard will contains one method by signature let say for 1 to 6 
arguments
and a generic method for more than 6.
Depending on the required method signature, the constructor of the guard 
will select
the applicable guard method.
In each guard method, you will check your global volatile field and all 
classes of all arguments,
if they haven't changed,  call the previous registered target method else
lookup for the new target method and patch the callsite with a new guard. 

For polymorphic call etc, you can store information in the callsite.

>   
>>> 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.
>   
Lot more bytecode to find the target method or lot of bytecode to call 
the target method ?
The former is not that important because the lookup should not be called 
often,
the later will destroy performance.
> 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.
>   
JavaMethodHandle main method are like any other method, it will be 
inlined like usual.
There is no magic behind.
>   
>> 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.
>   
I think it is.
>   
>> 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.
>   
In details, John correct me if I'm wrong,
Classes in MethodType should be classes loaded by the bootstrap class loader
except the ones uses to do the lookup.

That not a big deal because as you say all arguments (non primitive perhaps)
is a JRubyObject (correct with the right name).

> - Charlie
>   
Rémi