[9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

[John Rose]

On Jan 18, 2016, at 4:54 AM, Vladimir Ivanov <vladimir.x.ivanov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160119/3bb26897/attachment-0001.html>