Java Performance Degradation in JDK7 and JDK8

Jacob Wieland wieland at testingtech.com
Thu Apr 30 15:15:14 UTC 2015


thank you very much  - very interesting.

is there any estimate when a patch for 7/8 will be available?

2015-04-30 17:03 GMT+02:00 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


-- 
-- 
------------------------------
-------------------------------------------
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
<stanca at testingtech.com>
Fax         +49 30 726 19 19 20        Internet  www.testingtech.com
---------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------

UPCOMING EVENTS

SUBMIT YOUR TOPIC for the UCAAT 2015
Deadline: May 30, 2015ucaat.etsi.org/2015/CallForPresentations.html

Apr 21-23, 2015 | SAE Conference & Exhibition
Detroit, Michigan, USAwww.sae.org/congress/

Apr 28-30, 2015 | iqnite
Dusseldorf, Germanywww.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150430/11bfbaa5/attachment-0001.html>


More information about the compiler-dev mailing list