I was going to say it is unlikely to matter in production cases but might well hit test code which does extensive meta-programming, but actually, since it¹s a question of invalidations across _all_ sites, rather than any single one I think it might make a difference. I¹ll need to take a look at what our compilation counts eventually come to and experiment with changing the limits. We did work quite early on to limit the the extent of call site invalidations.
One thing that might affect this is how megamorphic call sites are handled. At the moment we keep a cache of classes, method handles, and switch points, and we check the switch point before calling the method handle. I had considered a change to bind the switch points to the method handles and thus allow those checks to be optimised out for methods called extensively from mega-morphia call sites, would that also fall foul of the compilation count being increased? I think there is definitely room for communicating more in the nature of a callsite to the JIT. Whether this should be around recompilation or perhaps more focused round inlining and type specialisation to avoid invalidations and recompilation would be my question. For example, method invocation sites may go megamorphic, and this currently forms a barrier to the JIT seeing the types in a way that doesn¹t really exist with standard invokeVirtual sites. If there was some feedback loop allowing sites to be cloned as methods are inlined, and a way to indicate this was allowed or desired, then that might allow significantly more optimisations to happen in invokeDynamic based languages. It would also probably be a horror to implement in the current model, but I¹m sure you guys can fix all that. :-) Duncan. On 20/01/2016, 11:54, "mlvm-dev on behalf of Vladimir Ivanov" <mlvm-dev-boun...@openjdk.java.net on behalf of vladimir.x.iva...@oracle.com> wrote: >MLVM folks, I'd like to hear your opinion about what kind of behavior do >you expect from JVM w.r.t. mutable call sites. > >There are valid use-cases when JVM shouldn't throttle the recompilation >(e.g., long-running application with indy-based dynamic tracing). Maybe >there's a place for a new CallSite flavor to clearly communicate >application expectations to the JVM? Either always recompile (thus >eventually reaching peak performance) or give up and generate less >efficient machine code, but save on possible recompilations. > >Best regards, >Vladimir Ivanov > >On 1/20/16 2:37 AM, John Rose wrote: >> On Jan 18, 2016, at 4:54 AM, Vladimir Ivanov >> <vladimir.x.iva...@oracle.com <mailto:vladimir.x.iva...@oracle.com>> >>wrote: >>> >>> The fix is to avoid updating recompilation count when corresponding >>> nmethod is invalidated due to a call site target change. >> >> Although I'm not vetoing it (since it seems it will help customers in >> the short term), I'm uncomfortable with this fix because it doesn't >> scale to large dyn. lang. applications with many unstable call sites. >> Put another way, it feels like we are duct-taping down a failsafe >> switch (against infinite recompilation) in order to spam a >> micro-benchmark: a small number mega-mutable call sites for which we >> are willing to spend (potentially) all of the JIT resources, including >> those usually allocated to application performance in the steady state. >> Put a third way: I am not comfortable with unthrottled infinite >> recompilation as a performance strategy. >> >> I've commented on the new RFE (JDK-8147550) where to go next, including >> the following sentiments: >> >>> There is a serious design tension here, though: Some users apparently >>> are willing to endure an infinite series of recompilations as part of >>> the cost of doing business; JDK-7177745 addresses this need by turning >>> off the fail-safe against (accidental, buggy) infinite recompilation >>> for unstable CSs. Other users might find that having a percentage of >>> machine time devoted to recompilation is a problem. (This has been the >>> case in the past with non-dynamic languages, at least.) The code shape >>> proposed in this bug report would cover all simple unstable call >>> sites (bi-stable, for example, would compile to a bi-morphic call), >>> but, in pathological cases (infinite sequence of distinct CS targets) >>> would "settle down" into a code shape that would be sub-optimal for >>> any single target, but (as an indirect MH call) reasonable for all the >>> targets together. >>> >>> In the absence of clear direction from the user or the profile, the >>> JVM has to choose infinite recompilation or a good-enough final >>> compilation. The latter choice is safer. And the >>> infinite recompilation is less safe because there is no intrinsic >>> bound on the amount of machine cycles that could be diverted to >>> recompilation, given a dynamic language application with >>> enough mega-mutable CSs. Settling down to a network of indirect calls >>> has a bounded cost. >>> >>> Yes, one size-fits-all tactics never please everybody. But the JVM >>> should not choose tactics with unlimited downsides. >> >> ‹ John >_______________________________________________ >mlvm-dev mailing list >mlvm-dev@openjdk.java.net >https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_ >mailman_listinfo_mlvm-2Ddev&d=CwIGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUr >LrDQYWSI&r=aV08z5NG4zOHLhrrnNlp8QUqO3qoRJCN9uQ9bkMSeqE&m=hJAS8YcL1L_GjSeHP >APOmxt0FJdHHHxFhzDQ8MvmlGY&s=5oO4O88gUQMGupvgF779GMNnLvUSUnYOGcvKCpcm8sU&e >= _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
