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

Tue Mar 11 12:13:47 UTC 2014

On 03/11/2014 12:59 PM, Vladimir Ivanov wrote:
> 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. *

Is this good or bad? It enables tools to see it (for example sampling 
profilers, etc...).

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140311/25dd4278/attachment-0001.html>