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

2014-03-12 Thread Peter Levart 

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.


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.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
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

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

2014-03-11 Thread Peter Levart 

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.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 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

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

2014-03-11 Thread 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.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 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

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

2014-03-11 Thread Vladimir Ivanov 

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.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 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

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

2014-03-11 Thread Peter Levart 

On 03/11/2014 03:05 PM, Vladimir Ivanov wrote:

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.


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 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.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 
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

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

2014-03-11 Thread Vladimir Ivanov 

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?

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.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
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

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

2014-03-10 Thread Vladimir Ivanov 

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 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

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

2014-03-10 Thread John Rose 
Reviewed. 

– John

 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 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

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

2014-03-10 Thread Christian Thalinger 
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 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

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

2014-03-10 Thread Vladimir Ivanov 

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 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

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

2014-03-09 Thread Christian Thalinger 
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 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