On 03/11/2014 03:05 PM, Vladimir Ivanov wrote:
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.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...).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.
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...
Regards, Peter
Best regards, Vladimir IvanovRegards, PeterThere'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 thatare 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 thecall. In fact, if prepend() ever throws exception (NPE in case array isnull?), 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.iva...@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.iva...@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 thesameas 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 parametertype is not assignable from the corresponding caller type. In this case, theadapter replaces all trailing arguments from the original trailingargument 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
