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

Tue Mar 11 14:05:31 UTC 2014

>> 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...).
For the purposes of sampling profilers (and other monitoring tools) 
@Hidden should be completely ignored.  These tools should use 
appropriate API to get the data.

I looked into the code and @Hidden has even less effect than I thought 
initially. It affects very limited set of cases - only users of 
JVM_FillInStackTrace (when filling exception's stack trace, 
Thread.dumpStack()). Calls to Thread.getStackTrace() from a separate 
thread omit stack trace filtering.

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
>