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.
Related Reports
Blocks :  
Relates :  
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:

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.