On Jul 11, 2018, at 9:32 AM, Peter Levart <peter.lev...@gmail.com> wrote: > > 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?
Here's my $0.02: - Performance does not seem to be important yet for MHP; Paul is mainly concerned with functionality. - But such implementation strategies are desirable for performance. - The ClassSpecializer mechanism is a good candidate for managing the tuple species (it was factored from BMH). - I think a reasonable balance would be for a MHP instance to factor into (a) a @Stable MH (or List::of), and (b) a @Stable tuple. Downsides of factoring MHP into MH and tuple sub-objects: - Three heap nodes instead of the minimum single node. - Indirection costs. (Note that constants fold through @Stable links including List::of or stable-array.) Upsides: - Fewer generated classes: One per interface, one per payload tuple, one per MH. - Possible shared code with publicly-visible tuple carrier API (probably needed for pattern "extractors"). More ideas: An alternative is to do a full-custom species for every distinct MHP combination. This might be OK, until people start to use MHP in earnest; then it will cause startup problems IMO. Factoring the MHP nodes makes the thing scale better in terms of static code, at a modest cost in heap flatness. If (long-term if) we want to flatten the MPH nodes, but only for hot-path MHPs (assuming in the long term a wide variety of usage), then we might try Vladimir's MH customization hack, which puts invocation counters on MH transform chains, and upgrades them in-place to use customized LFs if they get hot. Something like this could be done with MHP combos that turn hot. Perhaps existing MHPs that get hot could even be internally converted to delegate by one patched hop to a flattened version of the object, and new MHPs of the same syndrome would just generate the flattened version from the start, sans secret indirection. — John
