MethodHandle vs invodynamic (performance-wise)

[forum at x9c.fr]

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.


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