Java Performance Degradation in JDK7 and JDK8
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Apr 30 15:51:50 UTC 2015
On 30/04/15 16:15, Jacob Wieland wrote:
> thank you very much - very interesting.
>
> is there any estimate when a patch for 7/8 will be available?
We are currently playing with different patches - we will update this
discussion when we know more about which steps will be taken.
Regards
Maurizio
>
> 2015-04-30 17:03 GMT+02:00 Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com <mailto: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>
> <mailto: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>
>
> <mailto: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
> <tel:%2B49%2030%20726%2019%2019%2034>
> Email
> wieland at testingtech.com
> <mailto:wieland at testingtech.com>
> <mailto:stanca at testingtech.com
> <mailto:stanca at testingtech.com>>
> Fax +49 30 726 19 19
> 20
> <tel:%2B49%2030%20726%2019%2019%2020>
> Internet
> www.testingtech.com
> <http://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>
> <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/>
> <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>
> <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
> <tel:%2B49%2030%20726%2019%2019%2034>
> Email wieland at testingtech.com
> <mailto:wieland at testingtech.com>
> <mailto:stanca at testingtech.com
> <mailto:stanca at testingtech.com>>
> Fax +49 30 726 19 19 20
> <tel:%2B49%2030%20726%2019%2019%2020>
> Internet www.testingtech.com
> <http://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>
> <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/>
> <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>
> <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
> <tel:%2B49%2030%20726%2019%2019%2034>
> Email wieland at testingtech.com
> <mailto:wieland at testingtech.com>
> <mailto:stanca at testingtech.com
> <mailto:stanca at testingtech.com>>
> Fax +49 30 726 19 19 20
> <tel:%2B49%2030%20726%2019%2019%2020>
> Internet www.testingtech.com
> <http://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>
> <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/>
> <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>
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150430/1b05cf00/attachment-0001.html>
More information about the compiler-dev
mailing list