On 03/08/2015 01:38 PM, Jochen Theodorou wrote:
Am 08.03.2015 12:16, schrieb Remi Forax:
You need to restrict the set of method handles that are allowed to be
installed inside a CallSite corresponding to such kind of invokedynamic.
Something like: you can do any transformations you want on the arguments
but not on the receiver (no drop, no permute, no filter) and then you
need to call unconditionally a method handle created using findSpecial
on the super class.

unconditionally, like no guard?


There can be GWT, but it can only select one of target/fallback that are both from the restricted set of MHs.


That was my thinking too. I even started a proof-of-concept. The idea is as follows:

1) let verifier treat an invokedynamic <super-init> using a special system provided bootstrap method in the same way as it treats invokespecial super.<init>, meaning that such chaining to super constructor passes the verification
2) this system provided bootstrap method takes the standard parameters:
    - caller Lookup
    - invoked method name
    - invoked method type
- and an additional parameter, a MethodHandle of a static method that is supplied by language runtime and has the purpose to build a MH chain that dispatches the invocation to one of candidate super constructors selected by system provided bootstrap method

I started a proof-of-concept that tries to implement a similar setup, but instead of invoking super constructor, it invokes one of accessible superclass instance methods that have the same name as dynamically invoked name - this should translate to constructors nicely, I think.

Here's a preview of what I'm trying to do:


The Story.superInvokeBootstrap is an example of such system provided bootstrap method that is trusted to do the right thing and treated by verifier in a special way. It prepares a set of target method handles and wraps them in wrapper objects that provide an API similar to MethodHandle/MethodHandles (Story.MH/Story) but restricted in a way that allows only transformations that maintain an invariant where the 1st argument (the target of instance method) is left untouched and invoking any of derived MHs results in either throwing an exception or invokes one of the provided candidate MHs.

The language runtime must therefore provide a static MH-chain building method similar to the following:

    public static Story.MH buildDispatch(
        MethodHandles.Lookup callerLookup,
        String methodName,     // the invoked method name
        MethodType methodType, // the invoked type
        Story story,
        List<Story.MH> candidates) {


which uses Story.MH/Story API in a way that MethodHandle/MethodHandles API is used to construct and return a Story.MH that does the dispatch based on all arguments.

So Jochen, can you point me to an algorithm used for MultiMethods dispatch in Groovy and I'll try to prepare a proof-of-concept that uses it?

Regards, Peter

bye Jochen

mlvm-dev mailing list

Reply via email to