In the specific case below, of a concrete method implemented in a base class (abstract or not) which has no overriding methods in any loaded subclass, CHA will identify the fact that only a single possible target exists and get the speed you seek regardless of encountered polymorphism level at the call site, (so yes, works even in metamorphic call sites).
Getters and setters are great (and very common) examples of this. And when CHA can prove a single target, the cost is no higher than an invokeststic (assuming the object reference is already known to be non-null for some other reason in the same frame, which tends to overwhelmingly be the case). To Remi’s point, in cases that are monomorphic, guarded inlining can be so close to CHA in results that it’s hard to measure the difference, since the difference becomes a perfectly predicted cmp + jmp. When going metamorphic, CHA benefits (compared to guarded inlining) depend on the level of megamorphism and the JIT you end up using. E.g. HotSpot/OpenJDK will do biomorphic guarded inlining, and while the jmp is not perfectly predictable, it often is “very very predictable” (hardware branch predictors are amazing things). Falcon (in Zing) and the Graal JITs will both do guarded inlining on much more metamorphic cases (e.g. hexamorphic, septamorphic, or octamorphic guarded inlining have shown real benefits). But if your megamorphism level blows past the JITs guarded inlining levels, you end up with a vocal, and more importantly, loose the optimization benefits that come from inlining the target. In the case where there is a single target that CHA can identify, even that level of megamorphism will get the benefits of inlining. But in practice, those situations (where CHA is a win) are very rare these days (especially with the level of megamorphism that a Falcon and a Graal will put up with and still inline). On Monday, December 30, 2019 at 8:13:53 AM UTC-8, Brian Harris wrote: > > 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] > <javascript:>> wrote: > >> >> >> On Sun, Dec 29, 2019 at 10:22 AM Brian Harris <[email protected] >> <javascript:>> 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. >> >>> >>> Thanks >>> Brian >>> >>> -- >>> 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] >>> <javascript:>. >>> To view this discussion on the web, visit >>> https://groups.google.com/d/msgid/mechanical-sympathy/CAFtUM9Zt%2BwJvkDix_ZEYA%2B5u6hA86VQW7d5ceEyvxetiLvq%2BfA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/mechanical-sympathy/CAFtUM9Zt%2BwJvkDix_ZEYA%2B5u6hA86VQW7d5ceEyvxetiLvq%2BfA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> Sent from my phone >> >> -- >> 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] <javascript:>. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37EiQQKRfJvm3AVv87DiUpimxckyTVTtHRxgZDYUhfMC4g%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37EiQQKRfJvm3AVv87DiUpimxckyTVTtHRxgZDYUhfMC4g%40mail.gmail.com?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/d8c6431f-20c4-4183-b034-96ef723b7609%40googlegroups.com.
