Java Performance Degradation in JDK7 and JDK8

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Apr 29 09:29:29 UTC 2015


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150429/02a88a27/attachment-0001.html>


More information about the compiler-dev mailing list