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 > <head...@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 >> <head...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
