Profiling a simple scenario:

$ ~/Install/jdk9u20/bin/java -jar dist/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/compile-octane.js -- --iterations 5

...yields a few simple low-hanging fruits, here is one of them. Out of 320 seconds of run, 8 seconds are spent here:

8.410 jdk.nashorn.internal.ir.IdentNode.<init>(long, int, java.lang.String)
8.410 java.lang.String.intern()

I don't see off-hand why interning is needed for IdentNode.name. We compare through String.equals all the time. We escape the name via getName(), but Javadocs do not tell us to expect the interned String. If this is deduplication strategy, then doing the throw-away HashMap-based deduplication will save cycles going to VM, and save SystemDictionary from contamination.

Following up on this might require benchmarking to choose the proper interning/de-duplication strategy.