Java Performance Degradation in JDK7 and JDK8
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Apr 29 15:08:09 UTC 2015
On 29/04/15 15: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
> garbage collection.
Note that the javac code base is single threaded - there's absolutely no
parallelization going on; so what you see is the GC threads, which seems
to point to an higher-then-before memory activity.
I'll try your reproducer again by reducing the amount of memory and see
if I get somewhere.
Maurizio
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150429/d65fc991/attachment-0001.html>
More information about the compiler-dev
mailing list