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
