JDK-8056025 : jdk.nashorn.internal.codegen.CompilationPhase.setStates() is hot in class installation phase
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-08-26
  • Updated: 2015-06-04
  • Resolved: 2014-08-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u40Fixed 9 b29Fixed
Related Reports
Relates :  
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 12 seconds spent in class installation time, at least 2 seconds are spent here: 

12.690	jdk.nashorn.internal.codegen.CompilationPhase$12.transform(jdk.nashorn.internal.codegen.Compiler, jdk.nashorn.internal.codegen.Compiler$CompilationPhases, jdk.nashorn.internal.ir.FunctionNode)
2.110	jdk.nashorn.internal.codegen.CompilationPhase.access$100(jdk.nashorn.internal.ir.FunctionNode, jdk.nashorn.internal.ir.FunctionNode$CompilationState)
2.110	jdk.nashorn.internal.codegen.CompilationPhase.setStates(jdk.nashorn.internal.ir.FunctionNode, jdk.nashorn.internal.ir.FunctionNode$CompilationState)
2.100	jdk.nashorn.internal.ir.FunctionNode.accept(jdk.nashorn.internal.ir.visitor.NodeVisitor)

Attila says setStates should not be hot, since it is apparently the internal invariant-checking thing. The dumbest patch of all:

diff -r 494092ee7a01 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java
--- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java	Mon Aug 25 22:36:05 2014 +0200
+++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java	Tue Aug 26 12:24:39 2014 +0400
@@ -567,7 +567,7 @@
-            return setStates(fn.setRootClass(null, rootClass), BYTECODE_INSTALLED);
+            return fn.setRootClass(null, rootClass);

...on the current jdk9/dev and this simple benchmark:

$ for I in `seq 1 5`; do ~/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/compile-octane.js -- --iterations 1 2>&1 | grep "Class Installation"; done

...yields a big improvement. 

Before (setStates is called):
 [time] 'Class Installation'               2926 ms
 [time] 'Class Installation'               3426 ms
 [time] 'Class Installation'               3079 ms
 [time] 'Class Installation'               2844 ms
 [time] 'Class Installation'               2893 ms

After (setStates is not called):
 [time] 'Class Installation'               1668 ms
 [time] 'Class Installation'               1680 ms
 [time] 'Class Installation'               1674 ms
 [time] 'Class Installation'               1681 ms
 [time] 'Class Installation'               1720 ms

This is with JDK-8055954 applied, so may be the relative improvement without JDK-8055954 is worse.