JDK-8059234 : C1 NullCheckEliminator consumes a lot of time when dealing with large methods
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-09-26
  • Updated: 2019-01-15
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
tbdUnresolved
Related Reports
Blocks :  
JDK-8059760 - VM/JDK fixes for Nashorn performance (warmup/footprint, indy)
Relates :  
JDK-8059235 - Nashorn chokes compilers with large methods
Description
If you look how Hotspot compiles the Nashorn/Octane workloads, you will notice that C1 is spending a lot of time doing null-check elimination:
 http://cr.openjdk.java.net/~shade/8058968/new-output-2.txt

At least in Nashorn case, it seems to be connected with large methods being compiled. If we instrument Optimizer::eliminate_null_check to see what are the basic block counts, and how much time we spent in NCE with that method, then we can see something like this:
 http://cr.openjdk.java.net/~shade/8059234/bbcount-time-linear.pdf
 http://cr.openjdk.java.net/~shade/8059234/bbcount-time-log.pdf

Notice how the NCE time grows with basic block count: it seems to be N^k (k > 1), where N is the number of basic blocks. The reason for that seems to be more iterations to find a fixed point in NCE computation, because a minute change in entire graph forces us to revisit a significant part of it. We therefore waste a lot of time optimizing large methods with C1, while we probably better off to bail-out doing NCE on them, and hand them over to C2 for aggressive compilation.
Comments
Suggested code fix: http://cr.openjdk.java.net/~shade/8059234/webrev.00/ C1 NCE time is down with Nashorn/Octane benchmarks. Warmup slope is a bit better, but not a conclusive improvement: http://cr.openjdk.java.net/~shade/8059234/webrev.00.perf.txt I would think this is because without NCE working on mammoth methods generated by Nashorn, the code size is bigger (see linear scan and class emit times taking a hit). It seems to mean we the cutoff does not readily help this test. Need to reconsider later.
01-10-2014