If you go ahead and profile Nashorn doing the entire suite of benchmarks:

~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/run-octane.js

...then you will see this profile:
 http://cr.openjdk.java.net/~shade/8057967/native-call-tree-1.txt

There lots of <Unknown> things, and that is expected: Java code hides there. But, notice how bad we are at tracking the dependencies: out of 3070 seconds of CPU time, we spend 442 seconds (~15%!) trying to identify the dependencies to flush. It seems we are walking through InstanceKlass::_dependencies nmethods linked list, and trying to ask each nmethod if it needs deoptimizing. This is a linear search in the best case, and a very quick instrumentation with:
  http://cr.openjdk.java.net/~shade/8057967/ik-trace-1.patch

...shows an immense miss rate when walking through that list. Notice the list size is also *growing*:
  http://cr.openjdk.java.net/~shade/8057967/instrumented.log

We need to figure out whether we can:
 a) Get less nmethods in the InstanceKlass::_dependencies list;
 b) Re-index InstanceKlass dependency information based on the DepChange type and/or CallSite instance
 c) Provide better statistics for dependency tracking events (akin to the brain-dead patch used above)