BUG! Re: Regression in MH building for catchException?

[Charles Oliver Nutter]

Thanks John...I've seen a lot of commits landing, and figured things
are a bit fluxxy. I'm trying not to get too frustrated by it and keep
feeding you issues as they come up.

For the catchException issue, the code I provided should allow you to
reproduce. I have not dug any deeper than that example case. My
workaround is to simply not use the more direct invokedynamic binding
logic in cases where a catchException would end up dealing with > 10
arguments. It's a stopgap, of course, since it ends up being no faster
than the old IC.

For the methodHandleWalk issue (which I see quite a bit now on head),
I have not been able to narrow it down just yet. The failure appears
to come from this code, which I'm guessing is walking argument types
in the handle tree to determine how to inline:

  // Generate invoke. <=== LINE 1103 in methodHandleWalk.cpp
  switch (op) {
  case Bytecodes::_invokestatic:
  case Bytecodes::_invokespecial:
  case Bytecodes::_invokevirtual:
    emit_bc(op, methodref_index);
    break;
  case Bytecodes::_invokeinterface:
    Unimplemented();
    break;
  default:
    ShouldNotReachHere(); <==== REACHED
  }

I have some code in my local copy I could land to work around some of
these ShouldNotReachHere failures, but running the example JRuby
command against *current* (as of this exact moment) JRuby master
should trigger it fairly easily. Again, nothing reduced, but it is
reproducible. I will try to reduce this as I have time over the
weekend.

There were also some random crashes on the current macosx build I have
not seen on head. I'll assume they've been fixed and ignore them for
now.

- Charlie

On Sat, May 14, 2011 at 1:26 PM, John Rose <john.r.rose at oracle.com> wrote:
> 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
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>