Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8059234

C1 NullCheckEliminator consumes a lot of time when dealing with large methods

    Details

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                shade Aleksey Shipilev
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: