Still crashity crashing

[Rémi Forax]

Le 06/08/2009 02:40, Charles Oliver Nutter a écrit :
> On Wed, Aug 5, 2009 at 7:30 PM, Rémi Forax<forax at univ-mlv.fr>  wrote:
>    
>> I have seen some small rooms of improvement in the JRuby code
>> (apart from replacing  DynamicMethod by MethodHandle which is
>>   what must be done but which is also in my opinion a more than one week job
>> :)
>>      
>
> Nah, it's a day at most.

=> Cool :)

>   Here's the process:
>
> 1. When generating DynamicMethods that point at real Java code, also
> attach target class, method name, and signature info.
> 2. Use this info at runtime when preparing the call sites.
>    

You should try to cache the method handle in the DynamicMethod
to reuse the same MH for several call sites.

> And even if we went with a stupid-simple solution, I could switch on
> JRuby's reflection-based mode and simply unreflect the Method object
> each ReflectedMethod (extends DynamicMethod) would contain. The fact
> that we can juggle handle information immediately before installing it
> in the call site makes everything pretty easy.
>
> And here's a couple questions for you and John:
>
> 1. If we desired to expand JRuby's monomorphic inline caching in indy
> mode, could we simply chain together a series of GWTs that perform
> type comparisons? So we'd have something like
>
> at call site:GWT1
>    test: is receiver a String
>    target: call cached String method
>    fallback: GWT2
>      test: is receiver an Array
>      target: call cached Array method
>      fallback: GWT3
>      ...
>              fallback: slow lookup and perhaps add to or edit the GWT
> chain based on some heuristic
>
> Since the entire sequence would still inline (ideally) it would be
> similar to the regenerated call site logic that the DLR does...except
> way better, because it wouldn't interfere with the eventual targets
> inlining into the caller.
>    

Speaking for what I am knowing, i.e
without a special wildcard rule for inlining,
It's working for bi-morphic call but after that
local vtable (or selector table) implemented using table or
lookup switch are more efficient.

Something like:
let receiverClass = receiver.getClass();
switch(receiverClass.hashCode()) {
    case 0x1345678:
        return ...
    case 0x678456:
       // here there is a collision, very rare in practice, fallback to 
if..else
       if (receiverClass == String.class) {

        } else {

        }
     ...
}



> 2. Have you (or anyone else) thought much about how indy might
> eventually play with the tiered compiler? I could see the two working
> extremely well together. In my head, the first tier compilation would
> happen quickly and know about method handle chains, but also install
> appropriate profiling hooks that can gather information about those
> chains. For example, in the GWT case above, it would include branch
> profiling to see which of the types in the PIC were getting hit most
> often. Then the second tier compiler could do a better job of
> optimizing those paths.
>
> I know the tiered compiler work has slowed over the past few months,
> but I've also heard plans are still to make it a reality. Tiered
> compilation combined with indy would certainly be worth more than the
> sum of its parts, since dynamic, multi-stage optimization is the name
> of the game for fast dynamic languages.
>    

I wonder if tiered compilation is still an active project
since Steve Goldman passed away.
I know that someone new (I don't remember who)
was in charge to this project but I haven't seen
any news since.

> - Charlie
>    

Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090806/c121ec94/attachment.html