Hi Brian, I think I can safely assume your question was dictated by (perfectly valid) concerns about method dispatch cost in extremely latency sensitive sections of code. After all, we've used to work together on the same problem space in the same institution only weeks ago. Vitaly provided a valuable advice wrt default interface methods however I would supplement this with a general remark about dispatch cost:
invokeinterface > invokevirtual > invokestatic (omitted invokespecial and invokedynamic as I have confidence they are completely out of scope for your case) For dispatch other than static you'll also have to pay the cost of implicit null check. In some cases you can get substantial gains by cheating the runtime and using instanceof in conjunction with an if-else or switch to invoke a static method. If you can test this without committing atrocities on your code base I'd definitely recommend giving it a try. On Mon, 30 Dec 2019, 18:09 Remi Forax, <[email protected]> wrote: > > > ------------------------------ > > *De: *"Brian Harris" <[email protected]> > *À: *"mechanical-sympathy" <[email protected]> > *Envoyé: *Lundi 30 Décembre 2019 17:13:38 > *Objet: *Re: does call site polymorphism factor in method overrides? > > Good to know Vitaly! > So a poor example then. Better example is an abstract class with a method > implementation that no subtypes override, yet multiple subtypes are found > to be the receiver of a particular call site. Should we expect a > monomorphic call site in that case. > > On Sun, Dec 29, 2019 at 12:42 PM Vitaly Davidovich <[email protected]> > wrote: > >> >> >> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris <[email protected]> >> wrote: >> >>> Hello! >>> I was hoping to get one point of clarification about avoiding >>> megamorphic call sites, after reading these excellent articles: >>> >>> >>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>> >>> https://shipilev.net/blog/2015/black-magic-method-dispatch/ >>> https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef >>> >>> >>> When the runtime type of the call receiver is being observed, is it >>> considered whether that type actually overrides the method in question? For >>> example, when the method is an interface's default method that none of the >>> runtime call receivers override, can we expect to get a monomorphic call >>> site regardless of how many different receiver types are observed at >>> runtime, given there is only one method body to invoke? >>> >> In Hotspot, CHA is currently (AFAIK) disabled for default methods ( >> https://bugs.openjdk.java.net/browse/JDK-8036580). So you have to be >> careful putting hot code into them. Overriding the method in the impl and >> just calling super will at least restore some performance if type profiling >> at the callsite helps. >> > > CHA only avoids one cheap cmp + jump that will perfectly predicted, so i'm > not sure you will able be to see any perf difference apart from using a > micro benchmark. > And as far as i remember, CHA has never worked for abstract methods and > nobody care. > > >>> Thanks >>> Brian >>> >> > Rémi > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr > <https://groups.google.com/d/msgid/mechanical-sympathy/197490853.62864.1577729341131.JavaMail.zimbra%40u-pem.fr?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAHNMKAqHVvQn3j%3DB0umMGnLWieTVKEXaGAwaHVXSf6rexLDd-g%40mail.gmail.com.
