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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
