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

Java compiler performance degradation jdk1.7 vs. jdk1.6 should be amended

    Details

    • Subcomponent:
    • Resolved In Build:
      b68
    • CPU:
      x86_64
    • OS:
      linux
    • Verification:
      Verified

      Backports

        Description

        A DESCRIPTION OF THE REQUEST :
        When compiling a large project of generated java code (translated from ASN.1 and TTCN-3 input), the performance of javax.tools.JavaCompiler$CompilationTask.call is much worse in jdk1.7 as opposed to jdk1.6 on 64 bit architecture (did not check other architectures as there the input is too large).

        Where the 1.6 version needs 50 seconds, the 1.7 version needs over 130 seconds.

        The 1.7 version also needs much more memory and uses more CPU resources while doing so.

        The code to be compiled contains java 1.4 features only (no generics, no enums) and is compiled with target 1.5.

        It is distributed over 187 java source files which comprise 164 MB. The classes all reside in the same package and mostly use inner non-static classes and anonymous classes (sometimes several levels deep). The result is 48000 class files.

        The code is compiled against a runtime library of maybe 200 smaller classes and rt.jar.

        The classes are generated in memory in a special JavaFileManager (and kept via soft reference) and cached on file system in case of garbage collection. Profiling does not suggest any additional overhead there (observed behavior is similar in 1.6 and 1.7)

        Also, after compilation, there seems to be a memory-leak of com.sun.tools.javac.util.SharedNameTable$NameImpl (300,000 objects totalling 12 MB) and of com.sun.tools.javac.file.ZipFileIndex$Entry (35,000) even though JavaFileManager.close() has been called explicitly (and full gc has run several times). I don't know if that is related to the other issue.


        JUSTIFICATION :
        Since the performance of 1.7 in this respect is so much worse, we have to stick with using 1.6 and thus maybe cannot profit from advantages that 1.7 might have to offer (which I'm pretty sure it does).

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        The performance should be at least as good as with 1.6. Actually, I suppose it should be better as I'm sure that java 7 jvms and jit-compilers have also improved.

        I assume that the issue is caused by either additional checks that need to be performed or by other optimizations which in our case are pessimizations. However, if that is the case, at least some sort of backward compatibility options should be provided.

        CUSTOMER SUBMITTED WORKAROUND :
        Using java 1.6.

          Attachments

          1. GeneratedCode.jar
            2.47 MB
          2. noMembersClosureMisses-v1.patch
            5 kB
          3. noMembersClosureMisses-v2.patch
            6 kB
          4. TTthreeRuntime.jar
            1.40 MB
          5. TTtools.jar
            683 kB
          6. unregisterScopeListeners.patch
            3 kB

            Issue Links

              Activity

                People

                • Assignee:
                  jlahoda Jan Lahoda
                  Reporter:
                  webbuggrp Webbug Group
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: