Java Performance Degradation in JDK7 and JDK8
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Apr 30 15:03:26 UTC 2015
For the records - I've added a comment in
https://bugs.openjdk.java.net/browse/JDK-8039262
Reporting in as much detail as possible the underlying cause of the
performance regression.
Maurizio
On 29/04/15 18:38, Jan Lahoda wrote:
> In 9, the Scope listeners are (AFAIK) only needed to update the "mark"
> (so that the Types caches can detect obsolete entries). I think we may
> be able to avoid the listeners at the cost of slowing down getMark
> somewhat (getMark would ask the sub-scopes for their marks and sum the
> result). I'll try.
>
> Jan
>
> On 29.4.2015 19:16, Maurizio Cimadamore wrote:
>> Found it.
>>
>> The big offender is the listeners field in the CompoundScope (which is a
>> list).
>>
>> The test ends up creating huge listeners lists - probably because of
>> very deep inheritance hierarchies.
>>
>> If I avoid adding stuff to the listeners field in the compound scope, I
>> get back to a sane scenario:
>>
>> real 0m32.540s
>> user 1m15.298s
>> sys 0m1.126s
>>
>>
>> And the profiled memory usage is much more under control.
>>
>> So, looks like we need a way to prevent these listeners list to
>> overwhelm javac ;-)
>>
>> Maurizio
>>
>> On 29/04/15 17:51, Vicente-Arturo Romero-Zaldivar wrote:
>>> 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