Java Performance Degradation in JDK7 and JDK8
Jan Lahoda
jan.lahoda at oracle.com
Wed Apr 29 16:01:22 UTC 2015
On 29.4.2015 16:06, Jacob Wieland wrote:
> I have to admit, the reproducer is only a small part of the actual
> generated code. In my preliminary tests, it already sufficed to show a
> difference (also, the smaller code still worked with 32 bit while the
> whole code runs out of memory in all 32 bit versions which makes
> comparison much harder ;-) and which is why I need the 64 bit versions).
> If I test with the complete code which is much bigger, the results are
> as follows:
>
> jdk1.6u45(64bit) 2GB MaxMem - 1:30 minutes
> jdk1.7u75(64bit) 2GB MaxMem - > 6 min
> jdk1.8u31(64bit) 1GB MaxMem - > 15 min
> jdk1.8u31(64bit) 2GB MaxMem - > 10 min
> jdk1.8u31(64bit) 4GB MaxMem - 2:20 min (-source/-target 6 does not seem
> to have any effect)
>
> So, if you throw insane (in comparison with 1.6) amounts of memory at
> 1.7/1.8, it is only about a third as slow, but this still is
> unacceptable. I actually think it has to do with parallellization and
When I was looking at JDK-8039262, a significant contributing factor to
the slowdown (with enough memory and -source/-target 6) appeared to be
Check.checkOverrideClashes - I believe this does checks that were not
properly implemented in 6, contributing to the difference between 6 and
7 (which seems to be particularly visible for this testcase). I was
looking at the checks a few times, trying to write them
differently/faster while still performing the checks, but was not
successful in that yet, unfortunately.
Jan
> garbage collection.
>
> 2015-04-29 15:12 GMT+02:00 Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>>:
>
> On 29/04/15 12:44, Jacob Wieland wrote:
>> Hello Maurizio,
>>
>> are you sure that you used the 64bit versions of javac? I could
>> only observe the behavior with these.
> Yep I'm on a Ubuntu x64 machine. It's actually pretty standard
> hardware too - i.e. intel i5 (two cores, but OS sees 4 because of
> hyper-threading).
>> Also, I just tried with jdk8u31-64b and it takes AGES (still
>> running after 17 minutes where the jdk6 was done after 2), top
>> shows 4GB VIRT memory use and 350 % load (on a 4core processor).
> Maybe the reproducer you sent was incorrect?
>
> Maurizio
>
>>
>> So, I don't think it was that problem.
>>
>> 2015-04-29 12:00 GMT+02:00 Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com
>> <mailto:maurizio.cimadamore at oracle.com>>:
>>
>> These are the numbers I'm getting:
>>
>> JDK 9 (b42)
>>
>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or overrides a
>> deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>>
>> real 0m46.306s
>> user 2m17.489s
>> sys 0m2.166s
>>
>> JDK 8 (GA)
>>
>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or overrides a
>> deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>>
>> real 6m58.748s
>> user 8m43.546s
>> sys 0m2.132s
>>
>> JDK 7 (1.7.0_79)
>>
>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or overrides a
>> deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>>
>> real 0m28.341s
>> user 1m17.194s
>> sys 0m1.886s
>>
>>
>> As you can see there is a significant regression from JDK 7 to
>> JDK 8 which was caused by
>>
>> https://bugs.openjdk.java.net/browse/JDK-8043253
>>
>> (some stack trace analysis revealed the familiar pattern).
>> This has also been fixed in JDK 8u20 (as stated in the bug
>> evaluation).
>>
>> So, while JDK 8u20/9 is slower than JDK 7 (at least on my
>> machine), the numbers are more or less in the same ballpark
>> and the huge regression that was visible in earlier JDK 8
>> releases has now been fixed.
>>
>> If you are still experiencing the problem - can you please
>> also submit the specific compiler versions you are using in
>> your benchmark?
>>
>> Maurizio
>>
>>
>>
>> On 29/04/15 10:29, Maurizio Cimadamore wrote:
>>> Hi Jacob,
>>> Stay assured - as we'll definitively look into this issue (I
>>> see it's already assigned to one of my colleagues).
>>>
>>> What I can say (w/o looking too much at the attached
>>> artifacts) is that in general, javac has no issue with
>>> compiling a lot of sources at once; at one point the build
>>> system was structured in such a way that all the JDK classes
>>> were compiled at once - and that (which is way more than your
>>> 187 sources - i.e. at least 10x that) took less than 20
>>> seconds. SO there must some specific pattern triggering that
>>> issue.
>>>
>>> Given that you say you have 187 input sources and 48K output
>>> classes, I'd say you are using inner classes a lot. I wonder
>>> if you are hitting this:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8000316
>>>
>>> Maurizio
>>>
>>> On 24/04/15 09:49, Jacob Wieland wrote:
>>>> Hello Folks,
>>>>
>>>>
>>>> I still have the open problem
>>>> https://bugs.openjdk.java.net/browse/JDK-8039262 that the
>>>> javac performance has degraded significantly from 1.6 to 1.7
>>>> (and even worse to 1.8) in the 64bit versions. Since in our
>>>> context, we are dealing with a lot of generated source1.4
>>>> Java input (either split into very large files with inner
>>>> classes or big packages with lots of smaller classes),
>>>> compiler performance is critical for our tool and this
>>>> degradation forces us to continue recommending to our
>>>> customers to use Java 1.6 for large projects (as is the
>>>> norm) as 1.7 and 1.8 are pretty much unusable in this respect.
>>>>
>>>> Is anyone still working on this issue or is such significant
>>>> performance degradation not a serious issue?
>>>>
>>>> My observations so far are:
>>>> - it gets worse the more class files are being compiled/the
>>>> more files reside in the source path
>>>> - cpu usage goes through the roof over all available kernels
>>>> - memory usage is much higher
>>>> - garbage collection seems to be much more active
>>>>
>>>> Using -proc:none alleviates the problem slightly for the 1.7
>>>> version, but not for 1.8 (last we tested with
>>>> jdk1.8.0_31) where the performance difference is a factor 5
>>>> or more!
>>>>
>>>> I can understand that a more advanced compiler has
>>>> capabilities that a previous version does not have and thus
>>>> sometimes has
>>>> to do more work. But, it should still be possible
>>>> (especially if given the -source 1.4 or -source 1.5 option
>>>> as we do) to optimize it in such a way that unnecessary
>>>> checks for generics, overriding methods, closures,
>>>> annotations and other newer features can be turned off (if
>>>> they are to blame, which I actually doubt from my observations).
>>>>
>>>> I would really appreciate your help in this regard and I
>>>> think everyone would benefit from any bugfix you can offer
>>>> for this.
>>>>
>>>> BR, Jacob Wieland
>>>>
>>>> --
>>>> --
>>>> ------------------------------
>>>> -------------------------------------------
>>>> Dr. Jacob Wieland
>>>> Senior Software Engineer
>>>>
>>>> Testing Technologies IST GmbH
>>>> Michaelkirchstraße 17/18
>>>> 10179 Berlin, Germany
>>>>
>>>> Phone +49 30 726 19 19 34 Email
>>>> wieland at testingtech.com <mailto:stanca at testingtech.com>
>>>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>>>> <http://www.testingtech.com>
>>>> ---------------------------------------------------------------------------------------------------------------
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------
>>>>
>>>> UPCOMING EVENTS
>>>>
>>>> SUBMIT YOUR TOPIC for the UCAAT 2015
>>>> Deadline: May 30, 2015
>>>> ucaat.etsi.org/2015/CallForPresentations.html <http://ucaat.etsi.org/2015/CallForPresentations.html>
>>>>
>>>> Apr 21-23, 2015 | SAE Conference & Exhibition
>>>> Detroit, Michigan, USA
>>>> www.sae.org/congress/ <http://www.sae.org/congress/>
>>>>
>>>> Apr 28-30, 2015 | iqnite
>>>> Dusseldorf, Germany
>>>> www.iqnite-conferences.com/de/index.aspx <http://www.iqnite-conferences.com/de/index.aspx>
>>>> -----------------------------------------------------------------------------------------------------------------
>>>> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan
>>>> Pietsch, Pete Nicholson Handelsregister HRB 77805 B,
>>>> Amtsgericht Charlottenburg Ust ID Nr.: DE 813 143 070 This
>>>> email may contain confidential and privileged material for
>>>> the sole use of the intended recipient. Any review, use,
>>>> distribution or disclosure by others is strictly prohibited.
>>>> If you are not the intended recipient (or authorized to
>>>> receive for the recipient), please contact the sender by
>>>> reply email and delete all copies of this message.
>>>
>>
>>
>>
>>
>> --
>> --
>> ------------------------------
>> -------------------------------------------
>> Dr. Jacob Wieland
>> Senior Software Engineer
>>
>> Testing Technologies IST GmbH
>> Michaelkirchstraße 17/18
>> 10179 Berlin, Germany
>>
>> Phone +49 30 726 19 19 34 Email wieland at testingtech.com
>> <mailto:stanca at testingtech.com>
>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>> <http://www.testingtech.com>
>> ---------------------------------------------------------------------------------------------------------------
>>
>> -----------------------------------------------------------------------------------------------------------------
>>
>> UPCOMING EVENTS
>>
>> SUBMIT YOUR TOPIC for the UCAAT 2015
>> Deadline: May 30, 2015
>> ucaat.etsi.org/2015/CallForPresentations.html <http://ucaat.etsi.org/2015/CallForPresentations.html>
>>
>> Apr 21-23, 2015 | SAE Conference & Exhibition
>> Detroit, Michigan, USA
>> www.sae.org/congress/ <http://www.sae.org/congress/>
>>
>> Apr 28-30, 2015 | iqnite
>> Dusseldorf, Germany
>> www.iqnite-conferences.com/de/index.aspx <http://www.iqnite-conferences.com/de/index.aspx>
>> -----------------------------------------------------------------------------------------------------------------
>> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch,
>> Pete Nicholson Handelsregister HRB 77805 B, Amtsgericht
>> Charlottenburg Ust ID Nr.: DE 813 143 070 This email may contain
>> confidential and privileged material for the sole use of the
>> intended recipient. Any review, use, distribution or disclosure by
>> others is strictly prohibited. If you are not the intended
>> recipient (or authorized to receive for the recipient), please
>> contact the sender by reply email and delete all copies of this
>> message.
>
>
>
>
> --
> --
> ------------------------------
> -------------------------------------------
> Dr. Jacob Wieland
> Senior Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email wieland at testingtech.com
> <mailto:stanca at testingtech.com>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
> <http://www.testingtech.com>
> ---------------------------------------------------------------------------------------------------------------
>
> -----------------------------------------------------------------------------------------------------------------
>
> UPCOMING EVENTS
>
> SUBMIT YOUR TOPIC for the UCAAT 2015
> Deadline: May 30, 2015
> ucaat.etsi.org/2015/CallForPresentations.html <http://ucaat.etsi.org/2015/CallForPresentations.html>
>
> Apr 21-23, 2015 | SAE Conference & Exhibition
> Detroit, Michigan, USA
> www.sae.org/congress/ <http://www.sae.org/congress/>
>
> Apr 28-30, 2015 | iqnite
> Dusseldorf, Germany
> www.iqnite-conferences.com/de/index.aspx <http://www.iqnite-conferences.com/de/index.aspx>
>
>
> -----------------------------------------------------------------------------------------------------------------
> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete
> Nicholson Handelsregister HRB 77805 B, Amtsgericht Charlottenburg Ust ID
> Nr.: DE 813 143 070 This email may contain confidential and privileged
> material for the sole use of the intended recipient. Any review, use,
> distribution or disclosure by others is strictly prohibited. If you are
> not the intended recipient (or authorized to receive for the recipient),
> please contact the sender by reply email and delete all copies of this
> message.
More information about the compiler-dev
mailing list