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

Slow javac compile times in JDK 8

    Details

    • Subcomponent:
    • Resolved In Build:
      b20
    • CPU:
      x86_64
    • OS:
      windows_7
    • Verification:
      Not verified

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.8.0_05"
        Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
        Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

        ADDITIONAL OS VERSION INFORMATION :
        Microsoft Windows [Version 6.1.7601]

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        Core i7 860 2.8Ghz
        12GB RAM
        C: is an 335GB SSD disk 25% of space used

        A DESCRIPTION OF THE PROBLEM :
        I compare the time javac 1.7.0_55 and javac 1.8.0_05 use to compile a .java file.
        javac 8 use 6 seconds where javac 7 uses 1.5 seconds.

        This is a problem for us since the attached test code is a tiny example of the code we generate and compile using the Compiler API while running our program, and while the user is waiting.
        We compile it because we expect it to be evaluated many times.
        We compile many thousands of this size of functions.

        REGRESSION. Last worked in version 7u55

        ADDITIONAL REGRESSION INFORMATION:
        java version "1.7.0_55"
        Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
        Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)


        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        I used this in a .bat file to time the compile process.
        --
        echo %time%

        cmd /c "C:\Program Files\Java\jdk1.7.0_55\bin\javac.exe" C:\test\TestClass.java

        echo %time%

        cmd /c "C:\Program Files\Java\jdk1.8.0_05\bin\javac.exe" C:\test\TestClass.java

        echo %time%
        --

        Summary of the result I get is:
        java7 1.5s
        java8 6s
        e.g. Javac8 is a factor of 4 slower.



        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        I expect javac 7 and 8 to be same speed for java7 source code
        ACTUAL -
        javac 7 is a factor 4 faster than javac 8

        REPRODUCIBILITY :
        This bug can be reproduced always.

        ---------- BEGIN SOURCE ----------
        << attaching source file >>

        ---------- END SOURCE ----------

          Activity

          Hide
          coffeys Sean Coffey added a comment - - edited
          original source file attached.

          Test run from windows 7 :

          C:\Users\sc87771\Desktop>echo 18:37:30.14
          18:37:30.14
          C:\Users\sc87771\Desktop>cmd /c C:\jdk1.7.0_51\bin\javac TestClass.java
          C:\Users\sc87771\Desktop>echo 18:37:32.26
          18:37:32.26
          C:\Users\sc87771\Desktop>cmd /c C:\jdk8\bin\javac TestClass.java
          C:\Users\sc87771\Desktop>echo 18:37:39.37
          18:37:39.37
          C:\Users\sc87771\Desktop>cmd /c C:\jdk1.9.0\bin\javac TestClass.java
          C:\Users\sc87771\Desktop>echo 18:37:46.05
          18:37:46.05

          C:\Users\sc87771\Desktop>cat test.bat
          echo %time%
          cmd /c C:\jdk1.7.0_51\bin\javac TestClass.java
          echo %time%
          cmd /c C:\jdk8\bin\javac TestClass.java
          echo %time%
          cmd /c C:\jdk1.9.0\bin\javac TestClass.java
          echo %time%
          Show
          coffeys Sean Coffey added a comment - - edited original source file attached. Test run from windows 7 : C:\Users\sc87771\Desktop>echo 18:37:30.14 18:37:30.14 C:\Users\sc87771\Desktop>cmd /c C:\jdk1.7.0_51\bin\javac TestClass.java C:\Users\sc87771\Desktop>echo 18:37:32.26 18:37:32.26 C:\Users\sc87771\Desktop>cmd /c C:\jdk8\bin\javac TestClass.java C:\Users\sc87771\Desktop>echo 18:37:39.37 18:37:39.37 C:\Users\sc87771\Desktop>cmd /c C:\jdk1.9.0\bin\javac TestClass.java C:\Users\sc87771\Desktop>echo 18:37:46.05 18:37:46.05 C:\Users\sc87771\Desktop>cat test.bat echo %time% cmd /c C:\jdk1.7.0_51\bin\javac TestClass.java echo %time% cmd /c C:\jdk8\bin\javac TestClass.java echo %time% cmd /c C:\jdk1.9.0\bin\javac TestClass.java echo %time%
          Hide
          mcimadamore Maurizio Cimadamore added a comment - - edited
          Culprit of this performance regression is that lots of diagnostic objects are created in the middle of operator resolution; note that the position is only needed when compressing a method resolution diagnostic - i.e. to show something like:

          /home/maurizio/Desktop/Main.java:51: error: incompatible types: int cannot be converted to String
                  m(1);
                    ^

          Instead of:

          /home/maurizio/Desktop/Main.java:51: error: method m in class Test cannot be applied to given types;
                  m(1);
                  ^
            required: String
            found: int
            reason: argument mismatch; int cannot be converted to String

          Now, it's important to notice that these compressed diagnostics are not generated for operators - i.e. Resolve special cases operator diagnostics in a different way. As such there's never a real need to have positions attached to operator overload errors, as this position will be discarded anyway. There are two possible ways to tackle this problem:

          - defer position creation until when diagnostics actually have to be displayed
          - tweak overload resolution so that position is set to null during operator overload resolution


          Show
          mcimadamore Maurizio Cimadamore added a comment - - edited Culprit of this performance regression is that lots of diagnostic objects are created in the middle of operator resolution; note that the position is only needed when compressing a method resolution diagnostic - i.e. to show something like: /home/maurizio/Desktop/Main.java:51: error: incompatible types: int cannot be converted to String         m(1);           ^ Instead of: /home/maurizio/Desktop/Main.java:51: error: method m in class Test cannot be applied to given types;         m(1);         ^   required: String   found: int   reason: argument mismatch; int cannot be converted to String Now, it's important to notice that these compressed diagnostics are not generated for operators - i.e. Resolve special cases operator diagnostics in a different way. As such there's never a real need to have positions attached to operator overload errors, as this position will be discarded anyway. There are two possible ways to tackle this problem: - defer position creation until when diagnostics actually have to be displayed - tweak overload resolution so that position is set to null during operator overload resolution
          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          Delaying diagnostic position generation yields the following results:

          BEFORE:

          real 0m6.047s
          user 0m14.842s
          sys 0m0.419s


          AFTER:

          real 0m1.827s
          user 0m8.690s
          sys 0m0.370s


          In other words, compilation time goes back to JDK 7 levels.
          Show
          mcimadamore Maurizio Cimadamore added a comment - Delaying diagnostic position generation yields the following results: BEFORE: real 0m6.047s user 0m14.842s sys 0m0.419s AFTER: real 0m1.827s user 0m8.690s sys 0m0.370s In other words, compilation time goes back to JDK 7 levels.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f4ea5dca6498
          User: mcimadamore
          Date: 2014-06-18 12:53:53 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f4ea5dca6498 User: mcimadamore Date: 2014-06-18 12:53:53 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/f4ea5dca6498
          User: lana
          Date: 2014-06-20 17:39:40 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/f4ea5dca6498 User: lana Date: 2014-06-20 17:39:40 +0000

            People

            • Assignee:
              mcimadamore Maurizio Cimadamore
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: