What can we improve in JSR292 for Java 9?

[Peter Levart]

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?

@Jochen:

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

@Remi:

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:

http://cr.openjdk.java.net/~plevart/misc/invoke.Story/Story.java


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
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150308/364c2950/attachment-0001.html>