Java Performance Degradation in JDK7 and JDK8
Vicente-Arturo Romero-Zaldivar
vicente.romero at oracle.com
Wed Apr 29 16:51:28 UTC 2015
On 04/29/2015 09:43 AM, Maurizio Cimadamore wrote:
>
>
> On 29/04/15 17:01, Jan Lahoda wrote:
>> 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.
> I see the issue now - it is reproducible with the following memory
> parameter (at least in my machine):
>
> -J-Xmx768M
>
> This give around 20sec in JDK 6 and 10+ minutes in JDK 8.
>
> All the time seems to be spent in desugaring, most specifically in
> TransTypes.addBridges - it seems like that method calls
> Types.implementation a lot - so my theory was that the fact that javac
> consumes more memory, forces the GC to get rid of the cached entries
> in the implementation/members closure caches (since such entries are
> deliberately backed up by SoftReferences), which in turn completely
> trashes performances. I instrumented the code a bit and this is what I
> found:
>
> *) With -Xmx768M
>
> Impl cache misses = 3346926
> Members cache misses = 1042678
>
> real 7m0.335s
> user 25m51.517s
> sys 0m4.947s
>
>
> *) W/o -Xmx768M
>
> Impl cache misses = 3346839
> Members cache misses = 1042678
>
> real 0m32.377s
> user 1m25.881s
> sys 0m2.232s
>
> Long story short - cache misses do not play a factor in here - there
> are some minor differences, but nothing out of the ordinary and defo
> nothing that would explain a multi-minute slowdown! Any ideas?
use flight recorder?
Vicente
>
> Maurizio
>>
>> 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