John.Rose at Sun.COM
Thu May 21 23:42:53 PDT 2009
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:
> 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
> I presume this means the guardWithTest stuff isn't quite functional
> 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
> 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
> 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?
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:
My engineering goals for the coming 10 days are ambitious but not
(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)
More information about the mlvm-dev