Hi Valdimir, is there a reason to generate try { ... } catch(Throwable t) { if (Klass.isInstance(t)) { ... } throw t; } instead of: try { ... } catch(Klass t) { ... }
maybe because the Klass can be resolved by the wrong classloader ? RĂ©mi On 02/21/2014 12:59 PM, Vladimir Ivanov wrote: > Paul, thanks! > > Best regards, > Vladimir Ivanov > > On 2/21/14 2:11 PM, Paul Sandoz wrote: >> On Feb 20, 2014, at 6:57 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> >> wrote: >> >>> Paul, >>> >>> Thanks for the feedback! See my answers inline. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/ >>> >>> I finally figured out how to make caching work. This webrev contains these >>> changes. >>> >> +1 >> >> >>> I changed LF representation a bit and added 2 auxiliary method handles - >>> argument boxing and wrapping into Object[] and result unboxing. These >>> operations depend on actual type and can't be shared among arbitrary >>> combinators with the same basic type. They are used only during LF >>> interpretation and are completely ignored in compiled LFs. >>> >> >>>> src/share/classes/java/lang/invoke/MethodHandleImpl.java >>>> >>>> 634 // t_{i+2}:L=ValueConversions.unbox(t_{i+1}) OR >>>> ValueConversions.identity(t_{i+1}) >>>> 635 if (type.returnType().isPrimitive()) { >>>> 636 names[UNBOX_RESULT] = new >>>> Name(ValueConversions.unbox(type.returnType()), >>>> 637 names[TRY_CATCH]); >>>> 638 } else { >>>> 639 names[UNBOX_RESULT] = new >>>> Name(ValueConversions.identity(), >>>> 640 names[TRY_CATCH]); >>>> 641 } >>>> >>>> >>>> You could create the form without the identity transform for the >>>> non-primitive case? >>>> >>>> final int UNBOX_RESULT = type.returnType().isPrimitive() ? >>>> nameCursor++ : 0; >>>> ... >>>> >>>> if (UNBOX_RESULT > 0) { ... >>>> names[UNBOX_RESULT] = new >>>> Name(ValueConversions.unbox(type.returnType()), names[TRY_CATCH]); >>>> } >>> I can, but it complicates matching and compiling the pattern in >>> InvokerBytecodeGenerator. I decided to keep the shape uniform for all cases. >>> >> Ah, yes i see now, the code is simpler being kept uniform. >> >> Paul. >> > _______________________________________________ > 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