[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-mlvm-dev
Subject: Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (803412
From: Peter Levart <peter.levart () gmail ! com>
Date: 2014-03-12 11:54:10
Message-ID: 53204AE2.4090402 () gmail ! com
[Download RAW message or body]
On 03/12/2014 12:44 PM, Peter Levart wrote:
> 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.
...currently. But if this method is (re)used in other contexts in the
future, ...
>
> 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@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@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@openjdk.java.net
>>>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> mlvm-dev mailing list
>>>>>>>>>>> mlvm-dev@openjdk.java.net
>>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mlvm-dev mailing list
>>>>>>>>>> mlvm-dev@openjdk.java.net
>>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> mlvm-dev mailing list
>>>>>>>>> mlvm-dev@openjdk.java.net
>>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> mlvm-dev mailing list
>>>>>>>> mlvm-dev@openjdk.java.net
>>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mlvm-dev mailing list
>>>>>>> mlvm-dev@openjdk.java.net
>>>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>>>
>>>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic