JDK-8059235 : Nashorn chokes compilers with large methods
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 10
  • Priority: P4
  • Status: Closed
  • Resolution: Future Project
  • OS: generic
  • CPU: generic
  • Submitted: 2014-09-26
  • Updated: 2017-07-05
  • Resolved: 2017-07-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.
Other
tbd_minorResolved
Related Reports
Blocks :  
JDK-8059760 - VM/JDK fixes for Nashorn performance (warmup/footprint, indy)
Relates :  
JDK-8059234 - C1 NullCheckEliminator consumes a lot of time when dealing with large methods
Description
This is in relation to JDK-8059234. If we instrument C1 NCE and run Nashorn/Octane benchmark suite, and then sort the methods by compile time, we can then observe this:
 http://cr.openjdk.java.net/~shade/8059235/nashorn-c1-nce.log.gz

The last lines there are most interesting:
 34662	1541.935 ms, 11911 blocks: Done with null check elimination for method jdk/nashorn/internal/scripts/Script$Recompilation$2839$768791A$mandreel::_ZN16btCollisionWorld18addCollisionObjectEP17btCollisionObjectss(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

That is, a sample method took 1.5 seconds to do the a single phase in C1; and that is because it is a mammoth method with almost 12K basic blocks. While we can address the issue partially within JDK-8059234, Nashorn really needs to split the work into smaller methods to play nicely with JITs.