JDK-8058979 : Multiple 'call site target change' bailouts take significant amount of total compilation time
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-09-23
  • Updated: 2019-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8059760 - VM/JDK fixes for Nashorn performance (warmup/footprint, indy)
Relates :  
JDK-8206931 - Misleading "COMPILE SKIPPED: invalid non-klass dependency" compile log
Description
If you run Nashorn/Octane with:

jdk-jdk/test/nashorn $ ~/trunks/jdk-jdk/build/linux-x86_64-server-release/images/jdk/bin/java -XX:+CITime -jar ~/Install/jdk8u191-rh/jre/lib/ext/nashorn.jar  -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time script/basic/run-octane.js -- --iterations 1

....and this simple instrumentation patch:
 http://cr.openjdk.java.net/~shade/8058941/bailout-stat.patch

...then you will see we waste lots of compilations on final dependency checks before installing the nmethod:
 http://cr.openjdk.java.net/~shade/8058941/nashorn-octane.txt

  Bailout reasons:
    51.680 secs: CodeBuffer overflow
     1.492 secs: too many stack slots used
    94.501 secs: call site target change <---- !!!
     0.861 secs: concurrent class loading

I think we need to consider faster bailouts. Vladimir Ivanov speculated the underlying issue is about compiling the 
CallSite targets when CS targets actively mutate: by the time we finish the compilation, the target is already invalid.
Comments
Rebased the profiling patch to current jdk/jdk, and remeasured on Nashorn from 8u. The bailout reasons are now clearly "call site target change". My comment from 4 years ago still stands: maybe we should check for dependencies while compiling, and bail out much earlier than at code installation.
22-01-2019
[~jrose], what you are suggesting we already tried with JDK-7087838. See the last comment in JDK-7087838 as to why we didn't do it.
26-09-2014
Sure, in this particular scenario, the trigger might be CS targets mutating frequently. I am not fond of the idea of penalizing the megamutable sites, because that will eventually hit the legal cases of actively transforming programs. Instead, we should probably provide quicker aborts for the compilations when dependency checks fail? E.g. (re-)check the dependencies before starting a major compilation phase, like parsing, optimizing, regalloc, etc. This will also cover a generic case of non-megamutable code, but just the code that took too long to compile.
24-09-2014
A rare but significant failure mode of mutable call sites is "megamutability", where the call site changes so often that recompilation after every change becomes too expensive. Many of the bailouts are probably due to infrequently changing call sites, where the change happens during the compilation of the method containing the call site. Some of the bailouts may be due to megamutable sites. Those should be detected (via a small counter somewhere), and the optimistic inlining disabled (when the counter hits a limit).
24-09-2014