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

[Remi Forax]

Hi John, 
I understand that having the VM that may always recompile may be seen as a bug, 
but having the VM that bailout and stop recompiling, or more generally change the compilation strategy is a bug too. 

The problem here is that there is no way from the point of view of a dyn lang runtime to know what will be the behavior of the VM for a callsite if the VM decide to stop to recompile, decide to not inline, decide to inline some part of the tree, etc. 
Said differently, using an invokedynamic allows to create code shapes that will change dynamically, if the VM behavior also changes dynamically, it's like building a wall on moving parts, the result is strange dynamic behaviors that are hard to diagnose and reproduce. 

The recompilation behavior of the VM should be keep simple and predicatable, basically, the VM should always recompile the CS with no failsafe switch. 
If dyn lang runtime devs have trouble with that, they can already use an exactInvoker to simulate an indirect mh call and we can even provide new method handle combiners to gracefully handle multi-stable CS. 

regards, 
Rémi 

----- Mail original -----

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Mercredi 20 Janvier 2016 00:37:29
> Objet: Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause
> target method to always run in interpreter mode

> 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/20160120/f026b30f/attachment.html>