guardWithTest

[Charles Oliver Nutter]

Hello Fabio!

Fabio Kung wrote:
> I don't know if this is how guardWithTest is intended to be used, but I 
> found your code very clever. Making dynamic calls fall to the fallback 
> implementation in the first time and after that, always going to the 
> target method until cache is invalidated. I'm impressed! (and just 
> trying to understand all these mlvm new things better).

I think this is the right way to use guardWithTest, or at least it feels 
right to me :) I think there's just some unimplemented logic in the 
"spread" handle support.

> Correct me if I'm wrong, but then the JVM has the opportunity to cache 
> CallSites until their target changes (cache is invalidated, in your 
> case) and dynamic invocations could perform as much as "static" 
> invocations! Is entry.typeOk() just a flag check, or does it have some 
> complex logic? I'm asking because it's going to be called for every 
> dynamic invocation.

Yes, the idea behind this (I believe) is that if the JVM is able to see 
a path through primitive method handles all the way from a dynamic call 
site to a target, then the call will be at least as fast as an interface 
call, and potentially inlinable as well (whence comes many additional 
optimizations).

The typeOk check is just a comparison of two object tokens; if they do 
not match, either the incoming object is of a different type, or it is 
of the same type but has changed since the method was cached. The 
largest cost in this check is that the object field is thread-volatile 
at the moment. Hopefully we can find a faster way to check it.

> 1) are all ruby method calls going to be compiled (when not in 
> interpreter mode, off course) to a indy bytecode in JRuby?

Yes, when invokedynamic is present all Ruby dynamic calls would be 
compiled to invokedynamic. But there's also the possibility of wiring 
the interpreter into indy as well, to avoid some of the call overhead we 
have currently.

> 2) are there other benefits, besides CallSite caching by the JVM?

Inlining is the ultimate benefit. Indy will show the JVM a path from a 
callsite to a target and JVM will stitch those together allowing dynamic 
calls to enlist in method inlining just like normal Java calls.

It also reduces the amount of code we have to write considerably :)

- Charlie