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