[9] RFR (M): 8027827: Improve performance of catchException combinator
Paul Sandoz
paul.sandoz at oracle.com
Fri Feb 21 02:11:43 PST 2014
On Feb 20, 2014, at 6:57 PM, Vladimir Ivanov <vladimir.x.ivanov at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140221/a45695a0/signature.asc
More information about the mlvm-dev
mailing list