Re: The curious case of MHS.Lookup.unreflect on MethodHandle.invoke/invokeExact

2015-03-19 Thread John Rose 
On Mar 18, 2015, at 3:59 AM, Paul Sandoz paul.san...@oracle.com wrote:
 
 Perhaps such method handles were originally cached to avoid an explosion 
 (deliberate or otherwise) of class generation of LFs, but now there is more 
 sophisticated LF caching in place this is not necessary.?

That's probably correct.  Per-MT caching is overkill for all but the most 
crucial MHs.  — John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: The curious case of MHS.Lookup.unreflect on MethodHandle.invoke/invokeExact

2015-03-18 Thread Paul Sandoz 

On Mar 17, 2015, at 8:24 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 Paul,
 A call to the following:
 
   Object o = rmh.invokeExact((MethodHandle) null, new Object[]{});
 
 Will result in a:
 
   java.lang.UnsupportedOperationException: cannot reflectively invoke 
 MethodHandle
 
 However, the stack trace corresponds to the stack where the call to 
 unreflect was performed and not where the invocation occurs.
 The reason is that the preconstructed exception is thrown and not created on 
 every invocation:
  mh = mh.bindTo(new UnsupportedOperationException(cannot reflectively invoke 
 MethodHandle));
 

Yes.


 Further it does mh.withInternalMemberName(method, false), that i cannot 
 explain. Why do we need to re-associate the MH throwing the USO with the 
 member name corresponding to the MH.invokeExact/invoke method?
 I think the main reason is to keep direct method handle cracking API 
 (MethodHandles.revealDirect()) working for MethodHandle.invoke*.
 
 Actual method handle structure in this case is more complex than a simple 
 DMH, so additional trick with WrappedMember is needed to preserve an illusion 
 an ordinary direct method handle is returned.
 

Ah, i see, i had my suspicions in might be something to do with that.


 For such edge cases perhaps caching is not required.
 Agree, caching shouldn't be important for such cases.
 

Perhaps such method handles were originally cached to avoid an explosion 
(deliberate or otherwise) of class generation of LFs, but now there is more 
sophisticated LF caching in place this is not necessary.?

Thanks,
Paul.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: The curious case of MHS.Lookup.unreflect on MethodHandle.invoke/invokeExact

2015-03-17 Thread Vladimir Ivanov 

Paul,

A call to the following:

   Object o = rmh.invokeExact((MethodHandle) null, new Object[]{});

Will result in a:

   java.lang.UnsupportedOperationException: cannot reflectively invoke 
MethodHandle

However, the stack trace corresponds to the stack where the call to unreflect 
was performed and not where the invocation occurs.
The reason is that the preconstructed exception is thrown and not 
created on every invocation:
  mh = mh.bindTo(new UnsupportedOperationException(cannot reflectively 
invoke MethodHandle));



Further it does mh.withInternalMemberName(method, false), that i cannot 
explain. Why do we need to re-associate the MH throwing the USO with the member name 
corresponding to the MH.invokeExact/invoke method?
I think the main reason is to keep direct method handle cracking API 
(MethodHandles.revealDirect()) working for MethodHandle.invoke*.


Actual method handle structure in this case is more complex than a 
simple DMH, so additional trick with WrappedMember is needed to preserve 
an illusion an ordinary direct method handle is returned.



For such edge cases perhaps caching is not required.

Agree, caching shouldn't be important for such cases.

Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev