another question about megamorphic call sites in combination with MethodHandles

[Peter Levart]

On 03/22/2013 11:50 AM, Remi Forax wrote:
> On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
>> Am 22.03.2013 10:35, schrieb Remi Forax:
>>> On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
>>>> Am 22.03.2013 10:11, schrieb Remi Forax:
>>>> [...]
>>>>> I don't think it's a good idea to expose directly method handles to users,
>>>>> it's better to encapsulate it into a Groovy object corresponding to a
>>>>> function or a closure so you can add a bunch of invoke overloads.
>>>> what invoke overloads are you thinking of here?
>>> traditionnal ones,
>>> invoke(Object)
>>> invoke(Object,Object)
>>> ...
>>> invoke(Object...)
>> Well, I would probably use different name, to avoid the problem of
>> having a call with a single argument being an Object[] but then done
>> with invoke(Object...), which would use the array elements as arguments
>> instead of the array itself.
> the usual trick to fall into that trap is to have two forms:
>     invoke(Object[]) and invoke(Object, Object...)
>
>> We have this problem in Closure#call
>> already, if done from Java... Which is why the method will go. Our
>> groovy.lang.Closure will become only a thin wrapper ideally.
>>
>> Anyway... so you suggest having a general class we can use for
>> invocations, then make some method to request the invoker, which will
>> produce a subclass, with an implementation that can call the target?
> In my opinion, your closure object should be a wrapper around a
> MethodHandle.
> You should keep the call method (and even add several overloads) as a
> generic call mechanism with no inline optimisation. For the overload
> like call(Object), the call will be like a function call,
> so not something too bad.
>
> And if a user want a call to a specific closure to be inlined, the user
> should request a specific SAM implemented using a similar trick that the
> Java lambda will do (maybe?).
> The idea is to generate and reuse the same class for all instances of
> the same SAM interface with that the call of a method of the interface
> will be usually mono-morphic and inside the method of the generated
> class an invokedynamic will call the method handle that is inside the
> SAM proxy.
> Because it's an invokedynamic, it can cache several method handle in
> order to inline them with a guardWithTest that test method handle
> instances instead of checking object class as usual.

Hi Remi,

So how is this going to work? I mean the dispatch. If one SAM class is 
going to dispatch to several MethodHandle instances, how would that be 
more optimal then calling an interface method on several implementations 
(classes implementing the method), each calling it's target method 
directly or using a constant MethodHandle?

Regards, Peter

> It's basically a proxy generated once by SAM interface with an
> invokedynamic inside.
>
>> bye blackdrag
>>
> cheers,
> Rémi
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130323/a5dbcdcf/attachment.html