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.