[9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Wed Mar 12 11:44:36 UTC 2014

On 03/11/2014 05:46 PM, Vladimir Ivanov wrote:
>> So all you're achieving by annotating prepend() method is that any
>> exception stack trace, in case it is thrown inside the prepend() method,
>> will hide where it was thrown from. In case all LambdaForm frames
>> leading to the prepend() method were also hidden, the exception would
>> appear to be thrown from the invocation of the MH...
> Yes. Also, Thread.dumpStack() won't list it.
> Do you see any problem here?
>
It depends on what you're trying to achieve. Whether you're trying to 
hide the internals even in situations where something goes wrong or 
you're trying to simplify debugging in case something goes wrong. But I 
guess not much can go wrong in this method as I suspect the passed-in 
'array' can't be null, so it really doesn't matter.

Regards, Peter

> Best regards,
> Vladimir Ivanov
>
>>
>> Regards, Peter
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>> There's not much value in it in this particular case, but I 
>>>>> decided to
>>>>> reduce possible noise.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 3/11/14 3:35 PM, Peter Levart wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Excuse my ignorant question: What is the purpose of 
>>>>>> @LambdaForm.Hidden
>>>>>> annotation?
>>>>>>
>>>>>> I suspect it has to do with hiding the call frames in stack traces
>>>>>> that
>>>>>> are part of LambdaForm invocation chain. In this case, method:
>>>>>>
>>>>>>      private static Object[] prepend(Object elem, Object[] array)
>>>>>>
>>>>>> in MethodHandleImpl need not be annotated with this annotation, 
>>>>>> since
>>>>>> it's call frame is not on stack when one of the target methods is
>>>>>> executed. It's just a function used to calculate the argument of the
>>>>>> call. In fact, if prepend() ever throws exception (NPE in case
>>>>>> array is
>>>>>> null?), It would be preferable that it's call frame is visible in 
>>>>>> the
>>>>>> stack trace.
>>>>>>
>>>>>> Am I right or am I just talking nonsense?
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>
>>>>>> On 03/11/2014 12:12 AM, Vladimir Ivanov wrote:
>>>>>>> John, Chris, thanks!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>> On 3/11/14 3:08 AM, Christian Thalinger wrote:
>>>>>>>> Even better.
>>>>>>>>
>>>>>>>> On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov
>>>>>>>> <vladimir.x.ivanov at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Chris, thanks for the review.
>>>>>>>>>
>>>>>>>>> John suggested an elegant way to fix the problem - use
>>>>>>>>> asFixedArity.
>>>>>>>>>
>>>>>>>>> Updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Vladimir Ivanov
>>>>>>>>>
>>>>>>>>> On 3/8/14 4:51 AM, Christian Thalinger wrote:
>>>>>>>>>> Seems good to me.  I’d like to have another name for this 
>>>>>>>>>> method:
>>>>>>>>>>
>>>>>>>>>> +     private static Object invokeCustom(MethodHandle target,
>>>>>>>>>> Object... args) throws Throwable {
>>>>>>>>>>
>>>>>>>>>> On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
>>>>>>>>>> <vladimir.x.ivanov at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036117
>>>>>>>>>>> 84 lines changed: 74 ins; 3 del; 7 mod
>>>>>>>>>>>
>>>>>>>>>>> I have to revert a cleanup I did for 8027827.
>>>>>>>>>>> MethodHandle.invokeWithArguments (and generic invocation) has
>>>>>>>>>>> unpleasant
>>>>>>>>>>> peculiarity in behavior when used with VarargsCollector. So,
>>>>>>>>>>> unfortunately, invokeWithArguments is not an option there.
>>>>>>>>>>>
>>>>>>>>>>> Looking at the API (excerpts from javadoc [1] [2]), the 
>>>>>>>>>>> following
>>>>>>>>>>> condition doesn't hold in that case:
>>>>>>>>>>>    "trailing parameter type of the caller is a reference type
>>>>>>>>>>> identical
>>>>>>>>>>> to or assignable to the trailing parameter type of the 
>>>>>>>>>>> adapter".
>>>>>>>>>>>
>>>>>>>>>>> Example:
>>>>>>>>>>>    target.invokeWithArguments((Object[])args)
>>>>>>>>>>>    =>
>>>>>>>>>>> target.invoke((Object)o1,(Object)o2,(Object)o3)
>>>>>>>>>>>    =/>
>>>>>>>>>>>    target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
>>>>>>>>>>>
>>>>>>>>>>> because Object !<: Object[].
>>>>>>>>>>>
>>>>>>>>>>> The fix is to skip unnecessary conversion when invoking a 
>>>>>>>>>>> method
>>>>>>>>>>> handle
>>>>>>>>>>> and just do a pairwise type conversion.
>>>>>>>>>>>
>>>>>>>>>>> Testing: failing test case, nashorn w/ experimental features
>>>>>>>>>>> (octane)
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>>
>>>>>>>>>>> [1] MethodHandle.invokeWithArguments
>>>>>>>>>>> "Performs a variable arity invocation, ..., as if via an 
>>>>>>>>>>> inexact
>>>>>>>>>>> invoke
>>>>>>>>>>> from a call site which mentions only the type Object, and whose
>>>>>>>>>>> arity is
>>>>>>>>>>> the length of the argument array."
>>>>>>>>>>>
>>>>>>>>>>> [2] MethodHandle.asVarargsCollector
>>>>>>>>>>> "When called with plain, inexact invoke, if the caller type is
>>>>>>>>>>> the
>>>>>>>>>>> same
>>>>>>>>>>> as the adapter, the adapter invokes the target as with
>>>>>>>>>>> invokeExact.
>>>>>>>>>>> (This is the normal behavior for invoke when types match.)
>>>>>>>>>>>
>>>>>>>>>>> Otherwise, if the caller and adapter arity are the same, and 
>>>>>>>>>>> the
>>>>>>>>>>> trailing parameter type of the caller is a reference type
>>>>>>>>>>> identical to
>>>>>>>>>>> or assignable to the trailing parameter type of the adapter, 
>>>>>>>>>>> the
>>>>>>>>>>> arguments and return values are converted pairwise, as if by
>>>>>>>>>>> asType on a
>>>>>>>>>>> fixed arity method handle.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise, the arities differ, or the adapter's trailing
>>>>>>>>>>> parameter
>>>>>>>>>>> type
>>>>>>>>>>> is not assignable from the corresponding caller type. In this
>>>>>>>>>>> case, the
>>>>>>>>>>> adapter replaces all trailing arguments from the original
>>>>>>>>>>> trailing
>>>>>>>>>>> argument position onward, by a new array of type arrayType, 
>>>>>>>>>>> whose
>>>>>>>>>>> elements comprise (in order) the replaced arguments."
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>