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 <[email protected]>
>> 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
> [email protected]
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
