> De: "Vitaly Davidovich" <[email protected]> > À: "mechanical-sympathy" <[email protected]> > Envoyé: Lundi 30 Décembre 2019 19:43:27 > Objet: Re: does call site polymorphism factor in method overrides?
> On Mon, Dec 30, 2019 at 1:09 PM Remi Forax < [ mailto:[email protected] | > [email protected] ] > wrote: >>> De: "Brian Harris" < [ mailto:[email protected] | >>> [email protected] ] > >>> À: "mechanical-sympathy" < [ mailto:[email protected] | >>> [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 < [ >>> mailto:[email protected] >>> | [email protected] ] > wrote: >>>> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris < [ >>>> mailto:[email protected] | [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/ >>>>> | >>>>> http://www.insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/ >>>>> ] >>>>> [ https://shipilev.net/blog/2015/black-magic-method-dispatch/ | >>>>> https://shipilev.net/blog/2015/black-magic-method-dispatch/ ] >>>>> [ https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef | >>>>> 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 | >>>> 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. > Yeah, I don’t think CHA works for a type-megamorphic callsite that targets the > same method in the type hierarchy. I might be wrong, but pretty sure Hotspot > doesn’t handle this case - it ends up being a virtual call if there’s no > dominant receiver type. no, you're right. It's a known weakness of c2. But as far as i remember, it works with graal. > The big (potential) optimization loss here would be inlining; branch + call > overhead itself is unlikely to matter modulo truly trivial code called in a > tight loop. Missed optimizations due to inlining failure is the real problem. >>>>> Thanks >>>>> Brian >> Rémi 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/1385072861.66143.1577732212518.JavaMail.zimbra%40u-pem.fr.
