guardWithTest

[Fabio Kung]

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).

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.

Congrats!

Just two more questions:

1) are all ruby method calls going to be compiled (when not in interpreter
mode, off course) to a indy bytecode in JRuby?
2) are there other benefits, besides CallSite caching by the JVM?


On Fri, May 22, 2009 at 12:25 AM, Charles Oliver Nutter <
charles.nutter at sun.com> wrote:

> More information...with -Xint I don't get a hard crash, I get this
> exception:
>
> MemberName.java:406:in `newIllegalArgumentException':
> java.lang.IllegalArgumentException: cannot spread
> (java.lang.Object[])boolean to
>
> (org.jruby.runtime.ThreadContext,org.jruby.runtime.builtin.IRubyObject,org.jruby.runtime.builtin.IRubyObject,java.lang.String,org.jruby.runtime.builtin.IRubyObject)boolean
>        from MethodHandles.java:859:in `spreadArguments'
>        from MethodHandleImpl.java:312:in `makeGuardWithTest'
>        from MethodHandles.java:1031:in `guardWithTest'
>        from InvokeDynamicSupport.java:67:in `fallback'
>
> Seems to be a failure in the spread, no?
>
> - Charlie
>
> Charles Oliver Nutter wrote:
> > Ok, I was too intrigued by guardWithTest to not give it a try. Here's
> > the revised InvokeDynamicSupport I came up with. It seems like things
> > are wired correctly, but it results in a crash:
> >
> > http://gist.github.com/115901
> >
> > It crashes with a message like:
> >
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error (signature.cpp:60), pid=57856, tid=2954375168
> > #  Error: expecting (
> >
> > I presume this means the guardWithTest stuff isn't quite functional yet.
> >
> > A few notes on this:
> >
> > * I like this very much; it fits well our current call site logic. I
> > could also see how easy it would be to chain guardWithTest MHs to create
> > a polymorphic cache, which is super cool.
> > * One major improvement on my end would be to get our Ruby method
> > objects to actually *be* method handles, so they won't require the
> > intermediate code that, in this version, does nothing more than pass
> > arguments through.
> > * guardWithTest brings this much closer to being completely
> > primitive-MHs all the way through, and I think that's the right way for
> > us to be moving, yes?
> >
> > I'm eager to get more of this stuff wired up. I don't suppose there's
> > anything folks like me can do to help, is there?
> >
> > - Charlie
> >
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
Fabio Kung
http://www.fabiokung.com

Caelum - Ensino e Inovação
http://www.caelum.com.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090522/7f8bfc70/attachment.html