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, 4 seconds are spent in native hashcode for Node

4.550 jdk.nashorn.internal.codegen.ProgramPoints.setProgramPoint(jdk.nashorn.internal.ir.Optimistic)
4.650 java.util.HashSet.contains(java.lang.Object)
3.770 java.util.HashMap.containsKey(java.lang.Object)
3.900 java.util.HashMap.hash(java.lang.Object)
3.800 jdk.nashorn.internal.ir.Node.hashCode()
3.800 java.lang.Object.hashCode()

While the native hashcode can be fast, it still requires trip to the VM for initializing, it touches the object header and/or stores the identity hashcode somewhere, etc. We need to figure out: a) which of the Node subclasses delegate equals/hashCode to Node, and whether they should use their own hashCode/equals; b) whether the plain Java hashcode (e.g. static int HC; hashCode() { return HC++; }) would be better.