Sorry Paul for hijacking the thread, just answering to Remi ...
On 07/11/2018 05:31 PM, Remi Forax wrote:
----- Mail original -----
De: "Peter Levart" <peter.lev...@gmail.com>
À: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev"
<core-libs-dev@openjdk.java.net>
Envoyé: Mercredi 11 Juillet 2018 17:15:09
Objet: Re: RFR 8206955 MethodHandleProxies.asInterfaceInstance does not support
default methods
Hi Paul,
The patch looks ok. I hope IMPL_LOOKUP has access to all methods (even
if located in package-private interfaces and/or in concealed packages of
modules)?
Just a thought... Would it be possible to implement this API in terms of
LambdaMetafactory ?
Regards, Peter
Hi Peter,
not with the current LambdaMetaFactory, the LambdaMetaFactory only accept some
kind of method handles (constant method calls) not all kind of method handles.
That said the current implementation of MethodHandleProxies is very raw and not
very efficient, we should use the same idea as the lambda meta factory i.e spin
an anonymous class and use the mechanism of constant patching offer by
unsafe.defineAnonymousClass to inject the method handle into proxy so it will
work with any method handle.
For each interface, you should cache the bytecode of the anonymous class you
want to load and use defineAnonymousClass with the method handle each time
asInterfaceInstance is called.
If the generated class used invokeExact on the method handle, bytecode
should be generated specifically for each tuple (interface type, method
handle type), as the needed conversions of arguments/return values would
be specific for each distinct combination of the two types.
...which would still mean that you would define new anonymous class for
each method handle instance, just the bytecodes would be generated once
per (interface type, method handle type) combination.
The method handle could then be constant-folded in the generated class,
but selection of the underlying proxy class would still be governed by
the proxy instance which would be invoked via the interface method on
the functional interface. If the proxy instance could not be
constant-folded (i.e. was not assigned to static final field and used
from it), the combined invocation performance would still not be the
same as using invokeExact on the constant method handle, would it?
So perhaps for this API it is more suitable to:
- define the specific proxy class once per (interface type, method
handle type) combination (and cache the class itself, not just bytecode)
- have that proxy class implement a constructor taking the method handle
and assign it to a @Stable instance field
- implement the single interface method as parameter/return value
conversions around invokeExact on the method handle taken from @Stable
instance field
If such proxy instance was constant-folded, so would be the @Stable
method handle field, right?
What do you think of this strategy?
Regards, Peter
cheers,
Rémi
On 07/11/2018 12:43 AM, Paul Sandoz wrote:
Hi,
Please review this fix to MethodHandleProxies.asInterfaceInstance to support
default methods:
http://cr.openjdk.java.net/~psandoz/jdk/JDK-8206955-mh-func-iface-proxy-default-methods/webrev/
<http://cr.openjdk.java.net/~psandoz/jdk/JDK-8206955-mh-func-iface-proxy-default-methods/webrev/>
It probably requires a CSR, which i shall do after this review.
Thanks,
Paul.
