Crash with invokeDynamic on MethodMissing attempt

John Rose John.Rose at Sun.COM
Mon May 18 14:05:19 PDT 2009


Thanks for giving it a spin.  Your test case is a good one, but there  
seem to be logic errors.

This line:
site.setTarget(target);
should probably be
site.setTarget(this);

I'm surprised you don't get an error at that point.  Your target takes  
2 string args, while the indy site takes just one.  I think the call  
to CallSite.checkTarget should be throwing an error at this point.    
(This is also where static typing would help.)

The crash happens, perhaps, because the JVM is trying to raise a  
WrongMethodType and the assembly code has left the stack a little bit  
off-balance.  Our error-reporting paths need work.  (ASAP, since this  
will be lots of people's experience!)

It is probably good style to close the CallSite into the "method not  
found" handler, but in that case you don't need to redundantly close  
in the CallSite.name.

Thanks!

-- John

On May 18, 2009, at 1:25 PM, Yehuda Katz wrote:

> I'm trying to implement a simple method missing using invokeDynamic.  
> I've been able to make it work using static methods or static  
> methods that proxy to virtual methods (but not directly to virtual  
> methods). However, I'm trying to add support for including the name  
> of the method in the call to MethodMissing.
>
> Based on the Fidget demo, it seemed like the way to go would be to  
> create a custom JavaMethodHandle that encapsulated the logic. I  
> wasn't able to get it working (mostly in the setTarget step).  
> However, during some experiments, I encountered a segfault in the  
> JVM, so I figured I'd report it. The details (including the minimal  
> test case) are at http://gist.github.com/113717.
>
> That said, I'm curious about the appropriate way to wire this up.  
> I'm rather new to all of this, so I'm probably missing something  
> obvious.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090518/2149768f/attachment.html 


More information about the mlvm-dev mailing list