On 02/14/2011 06:50 PM, fo...@x9c.fr wrote: > Le 14 févr. 2011 à 15:05, Rémi Forax a écrit : > >> Le 14/02/2011 09:51, fo...@x9c.fr a écrit : >>> Le 13 févr. 2011 à 20:38, Rémi Forax a écrit : >>> >>>> On 02/13/2011 07:00 PM, fo...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
