Java Performance Degradation in JDK7 and JDK8
Jan Lahoda
jan.lahoda at oracle.com
Wed Apr 29 17:38:16 UTC 2015
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