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

[Vladimir Ivanov]

> 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?

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
>>>
>