guardWithTest

[John Rose]

On May 21, 2009, at 8:19 PM, 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 (

In parallel with slide authoring, this is exactly the bug I'm going  
after.

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

That's what it's for.  Actually, I think the design is over-simple,  
since it mandates an if-then-else structure.  If you really want a  
PIC, you probably want a switch/case structure, which is better  
expressed by (the mighty) combineArguments.

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

I think that would work.  Actually, one of the nice (maybe  
indispensible) side benefits of JavaMethodHandle is you can build your  
own subtypes with as much additional API as you want, co-existing with  
a method handle identity.  So you can have side queries on your Ruby  
methods while still allowing calls to come in the "front door" via  
((MethodHandle)myRubyMethod).invoke.  (A cast or assignment conversion  
is currently necessary.  Maybe we can dispense with it with a little  
more thought about language design.)

> * 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?

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?

I hesitate to suggest this, but since I'm really busy with slides and  
JVM work, you (or someone) might want to dive into the Java runtime  
code for method handles, and see about (a) adding more unit tests to  
the "meth" project which (b) force features like guardWithTest to  
work, necessarily (c) debugging said features into existence.  (Since  
you asked. :-)  It's not fundamentally complicated; it's more a case  
of deciphering the patterns already in the code and extending them.   
But if it doesn't happen I'll certainly get around to it.

The unit tests (along with a workable ant/netbeans setup for  
developing */dyn/*.java) are here:
   http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/meth/

My engineering goals for the coming 10 days are ambitious but not  
quite impossible:
(a) helping you get JRuby better integrated with method handles & indy.
(b) fixing JVM bugs (with Christian)
(c) removing blockages to performance in the compiler (with Christian)
(d) removing blockages to integration and performance in the runtime  
(fill in missing paths in the Java runtime)

-- John