Charles Oliver Nutter
charles.nutter at sun.com
Thu May 21 21:59:40 PDT 2009
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
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
> 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 :)
More information about the mlvm-dev