BUG! Re: Regression in MH building for catchException?

[John Rose]

Sorry about the recent instability, Charlie.  We are moving to a more robust system, using ricochet frames to manage argument list transformation, instead of the previous setup, which was a mix of up to 10 arguments plus varargs and/or NYI.

I want to turn your bugs around quickly, and can use some help:  Any minimized test cases to reproduce these failures would help use focus in quickly on the code that needs tweaking.

To answer your question about the intermediate Object[] box:  The new frames replace the Object[] box by holding all the temporary state spread out on the stack.  The only reasons we have the Object[] box are (1) SPARC doesn't support RF's yet, and (2) we haven't transitioned all the transform-building code non-boxing.  Working with GWT today; would like to fix the exception problem at the same time; need a representative test case.

-- John

On May 14, 2011, at 8:44 AM, Charles Oliver Nutter wrote:

> Ok, this looks like a bug. Whenever the exception handler passed to
> catchException will need to handle > 10 args, it fails to bind. I've
> created a small example here: https://gist.github.com/972331
> 
> This could be a general bug in spreadArguments...I have not looked
> into the JDK code yet.
> 
> I'm going to work around it for now by having JRuby dispatches with 3
> Ruby args + block only dispatch through an IC. It will slow those
> methods down, but should avoid this failover point.
> 
> On a related note...how many arguments can we expect MH optimization
> to inline straight through, without an intermediate Object[] box? I do
> need to rework how these handles are wired up, but I may still get
> close to this 10-arg failover in some cases.
> 
> - Charlie
> 
> On Sat, May 14, 2011 at 10:06 AM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> Still getting an error, but it's different now (updated using
>> Stephen's script a few minutes ago):
>> 
>> Caused by: java.lang.IllegalArgumentException: spread on
>> handleBreakJump(BreakJump,CacheEntry,ThreadContext,IRubyObject,IRubyObject,String,IRubyObject,IRubyObject,IRubyObject,Block)IRubyObject
>> with Object[]
>>        at java.lang.invoke.MethodHandleImpl.spreadArguments(MethodHandleImpl.java:765)
>>        at java.lang.invoke.MethodHandleImpl.spreadArguments(MethodHandleImpl.java:752)
>>        at java.lang.invoke.MethodHandleImpl.makeGuardWithCatch(MethodHandleImpl.java:1148)
>>        at java.lang.invoke.MethodHandles.catchException(MethodHandles.java:2139)
>>        at org.jruby.runtime.invokedynamic.InvokeDynamicSupport.<clinit>(InvokeDynamicSupport.java:1457)
>> 
>> I'll look into my code and see if maybe this is an API change I'm not
>> handling properly...
>> 
>> - Charlie
>> 
>> On Thu, May 12, 2011 at 8:58 AM, Charles Oliver Nutter
>> <headius at headius.com> wrote:
>>> JRuby invokedynamic bindings that use catchException appear to blow up
>>> with a current MLVM build (as of a few minutes ago). The error is the
>>> same in every case:
>>> 
>>> Caused by: java.lang.IllegalArgumentException: spread on
>>> invoke_F9(CacheEntry,ThreadContext,IRubyObject,IRubyObject,String,IRubyObject,IRubyObject,IRubyObject,Block)IRubyObject
>>> with Object[]
>>>        at java.lang.invoke.MethodHandleImpl.spreadArguments(MethodHandleImpl.java:764)
>>>        at java.lang.invoke.MethodHandleImpl.spreadArguments(MethodHandleImpl.java:751)
>>>        at java.lang.invoke.MethodHandleImpl.makeGuardWithCatch(MethodHandleImpl.java:1152)
>>>        at java.lang.invoke.MethodHandles.catchException(MethodHandles.java:2139)
>>>        at org.jruby.runtime.invokedynamic.InvokeDynamicSupport.<clinit>(InvokeDynamicSupport.java:1356)
>>> 
>>> The same catchException call works properly on current macosx build. I
>>> have not done any bisecting to determine what openjdk/mlvm commit
>>> introduced this problem.
>>> 
>>> Reproducible with even the fib benchmark by running this way:
>>> 
>>> jruby -d -X+C --server bench/bench_fib_recursive.rb 10 35
>>> 
>>> - Charlie
>>> 
>> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev