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

[Vladimir Ivanov]

Peter,

You raised totally valid question.

I marked MethodHandleImpl.prepend with @Hidden annotation because it is 
internal implementation detail of JSR292.

You are right that normally a callee can't see it on stack. But it's 
possible to observe it when stack trace is queried from a separate thread.

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