Java Performance Degradation in JDK7 and JDK8

Wed Apr 29 10:00:45 UTC 2015

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

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