MethodHandle vs invodynamic (performance-wise)
Rémi Forax
forax at univ-mlv.fr
Mon Feb 14 10:13:27 PST 2011
On 02/14/2011 06:50 PM, forum at x9c.fr wrote:
> Le 14 févr. 2011 à 15:05, Rémi Forax a écrit :
>
>> Le 14/02/2011 09:51, forum at x9c.fr a écrit :
>>> Le 13 févr. 2011 à 20:38, Rémi Forax a écrit :
>>>
>>>> On 02/13/2011 07:00 PM, forum at x9c.fr wrote:
> (...)
>
>
>>>> # p#get_x;;
>>>>
>>>> p#get_x is also an invokedynamic.
>>> This one is a tricky one...
>>> For non-camlists "obj#meth" is the syntax for calling the method "meth"
>>> over the object "obj". This is tricky because Java and Caml objects are
>>> *really* different (e. g. nominal vs structural typing) and to be compatible
>>> with the original Caml implementation, I have constraints over the way
>>> to encode an object instance. To put it short, it entails having a table for
>>> method dispatch, that maps method identifiers to closures.
>> That why you should use invokedynamic here. You should use guardWithTest
>> to create
>> an inlining cache at callsite to avoid the method dispatch lookup if the
>> receiver at callsite
>> as always the same type.
>>
>> Instead of object.table["meth"].invokeExact you should generate
>> if (object.class == Foo.class)
>> fastpath.invokeExact // with fastpath = Foo.table["meth"]
>> else
>> object.table["meth"].invokeExact
>>
>> slides 6-11 of
>> http://weblogs.java.net/sites/default/files/indydroid_-_FOSDEM.pdf
>> explain how to implement an inlining cache in Java.
> Thanks for the pointer.
> OCaml already implements a cache for method calls:
> - every method has a unique integer id;
> - for every place in the code where a method is called (*),
> we keep the id of the last method actually called along
> with the closure implementing the method;
> - a cache miss leads to a dichotomic search among
> method ids for the destination object.
> Given these, I cannot say for sure that an invokedynamic-based
> solution would be faster. As you pointed out before, MethodHandles
> are a little slower but it seems that the cache miss is more costly
> in the setting you presented at FOSDEM.
In the slides, a cache miss is costly the first time, after it can't
miss again
because you create a tree of 'if'.
Anyway, you can implement exactly the algorithm of OCAML with a
guardWithTest
(the test will test the global id) if you want.
invokedynamic will guarantee you that the whole block will be inlined,
i.e the closure
is inlined into the callsite.
>
> > From all the information you provided, my (temporary?) conclusion
> is that the way to go for OCaml on the JVM is to use method handles.
> This is what is implemented today (release expected "soon"), and was
> wondering whether I should investigate an alternative invokedynamic-based
> solution.
>
> Thanks again for the insight.
>
>
> Kind regards,
>
> Xavier Clerc
>
> (*) there is not so many code point, as objects are not widely used in OCaml
Rémi
More information about the mlvm-dev
mailing list