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

C2 recompilations cause high memory footprint

    XMLWordPrintable

Details

    • b20

    Backports

      Description

        While playing with the new compiler memory statistic, I saw that +StressRecompile causes a ~x2 increase in memory used during compilations. That confused me since I would have thought a recompilation starts memory-wise with a clean slate.

        ----

        Baseline: highest peak during compilation is ~60 MB, caused by compilation of java/lang/invoke/LambdaForm$Kind::<clinit> with ~18k nodes.

        `./images/jdk/bin/java -XX:CompileCommand='collectmemstat,*.*' -XX:-StressRecompilation -Xcomp -Xbatch -cp $REPROS_JAR de.stuefe.repros.Simple`


        NMT:

        ```
        - Compiler (reserved=275KB, committed=275KB)
                                    (malloc=79KB #30) (peak=93KB #35)
                                    (arena=196KB #4) (peak=59292KB #11) << peak
        ```


        Compiler.memory:

        ```
        total NA RA #nodes time type #rc thread method
        (3/1425)
        59063K 13406K 40025K 18345 6,174 c2 2 0x00007fdc2c28e7b0 java/lang/invoke/LambdaForm$Kind::<clinit>(()V)
        ```

        ----

        StressRecompile: highest peak during compilation is ~112 MB, same method, sameish node count.

        `./images/jdk/bin/java -XX:CompileCommand='collectmemstat,*.*' -XX:+StressRecompilation -Xcomp -Xbatch -cp $REPROS_JAR de.stuefe.repros.Simple`


        NMT:

        ```
        - Compiler (reserved=289KB, committed=289KB)
                                    (malloc=93KB #35) (peak=107KB #40)
                                    (arena=196KB #4) (peak=115628KB #11) << peak
        ```

        Compiler.memory:

        ```
        total NA RA #nodes time type #rc thread method
        (16/1434)
        112M 13469K 94987K 18791 16,451 c2 2 0x00007f790428e7b0 java/lang/invoke/LambdaForm$Kind::<clinit>(()V)

        ```

        ----

        60M -> 112M. In both cases, a large part of the memory was allocated in resource areas. Its relative size compared to the total spike size increased.

        Therefore it looks to me like we accrue a lot of memory in ResourceArea over recompilations.

        As a test, I artificially increased the number of recompilations even further. As expected, memory footprint went up further.

        Attachments

          Issue Links

            Activity

              People

                stuefe Thomas Stuefe
                stuefe Thomas Stuefe
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: