JDK-8057588 : Lots of trivial classes are generated by Nashorn compiler
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-04
  • Updated: 2015-06-04
  • Resolved: 2014-09-05
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.
JDK 8 JDK 9
8u40Fixed 9 b31Fixed
Related Reports
Relates :  
JDK-8057703 - Still, lots of trivial classes are generated by Nashorn compiler
Description
Running the fresh Nashorn with dumping all classes:

~/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 -d=generated/ test/script/basic/compile-octane.js -- --iterations 1

...yields an interesting tidbit: there are lots of trivial classes generated:
 http://cr.openjdk.java.net/~shade/8057588/nashorn-generated-classes-1.list

Notice how bytecode sizes have a very long tail in lower-sized classes. 3300/4900 of all classes seem to be those tiny classes. Disassembling a few of those tiny classes yields the almost the same content:

Compiled from "file:/home/shade/trunks/jdk9-dev/nashorn/test/script/basic/../external/octane/pdfjs.js"
public class jdk.nashorn.internal.scripts.Script$Recompilation$235$1$pdfjs$cu2 extends jdk.nashorn.internal.scripts.JS {
  public static final boolean strictMode;

}

...maybe we can cache them? Having all these tiny splices floating around are probably contaminating the symbol table with redundant string symbols from all those "jdk.nashorn.internal.scripts.Script$Recompilation$235$1$pdfjs$cu2".
Comments
I'll look at minimizing the new stage, I can piggy back on the ordinary compiler I think
05-09-2014
Current fix does not affect the compilation performance much: for I in `seq 1 10`; 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 "\[time\]"; done Was: (51.0 +- 1.4) s Now: (51.9 +- 1.2) s ...however, new stage takes considerable time, can be optimized down? [time] 'Tag Compile Units Used' 1231 ms
05-09-2014
I'll take a look!
05-09-2014
Unless Nashorn dumper lies to me, we do indeed emit lots of classes like these.
04-09-2014
"cu" stands for "compilation unit" -- we have a heuristic where we both chop up too large methods into smaller ones (so they don't exceed the 65535 length limit), and too large classes into smaller ones. A class with only just a boolean is completely useless. If we're really emitting this, it's a bug in the code generator where it emits a "compilation unit" class that was allocated, but then left unpopulated.
04-09-2014