Java Performance Degradation in JDK7 and JDK8
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Apr 29 17:16:17 UTC 2015
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