Seems like the best choice is to start from a couple of easy heuristics:
* if there is only one loaded class to implement the interface, choose it
* if there are more, choose the one with it's method invoked earlier
(compiled
by some JIT, possibly, some other JIT),
* if we have many candidate methods that are compiled, choose the most
frequent
one (need a method-entry profile, the feature is likely to stay
untouched for
a while, I guess)
1. Does anybody have some additional elegant ideas?
Egor, I'm interested in devirtualizer improvement too.
IMO the profile based devirtualization will probably have the best results
and is easy to implement and to check: infrastructure in Jitrino is ready to
do it right now with a help of entry-backedge profile collected for OPT by
JET.
+ more ideas I have:
1) to use edge profiler as value based one if initial compilation
devirtualize all possible dispatches and count their edge frequencies.
2) implement a real value profiler - this is not an easy task, but may be
reused in other optimizations
3) Add special annotations to classlib code about the most probable
dispatch. E.g. if the variable type does not depend on user's environment
and developer can prove that 90% of time the variable is of specific class -
JIT can read this annotation from method during the compilation and to
devirtualize it.
I will read more about other devirtualization techniques we can use and will
reply in a several days with results.
--
Mikhail Fursov
