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 220 seconds of run, ~5 seconds are spent here:

6.160 jdk.nashorn.internal.parser.Parser.parse()
6.160 jdk.nashorn.internal.parser.Parser.parse(java.lang.String, int, int, boolean)
4.830 jdk.nashorn.internal.parser.Lexer.<init>(jdk.nashorn.internal.runtime.Source, int, int, jdk.nashorn.internal.parser.TokenStream, boolean)
4.830 jdk.nashorn.internal.runtime.Source.getContent()
4.820 java.lang.Object.clone()

Sundar tells me that defensive copy is needed to shut FindBugs up, which means we could gain the performance back by sharing the original char[] via getContent()