Skip to Main Content

Java HotSpot Virtual Machine

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Migration from JRE 1.6 to JRE 1.7 caused performance issues (due to CodeCache flushing)

Sandro SansoneJul 24 2014 — edited Aug 22 2014

Hi,

During the past few days I have been fighting with an issue happening after migrating from jre 1.6 (1.6.0_30) to jre 1.7 (1.7.0_65).
I want to share this experience with you, so that (hopefully) you don’t have to deal with it

I presume this bug has been fixed in jdk 8 and it is same as the following in which the affected version is hs24 (jdk 7) and fixed in hs25 (jdk8):

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8012547

I opened an official bug request for this. I would like to have your opinion on why such compatibility issue has not been ported back in jre 7 (hs24), considering that it comes out just moving from jre6 to jre7

Below you can find the detail of the issue.

Thanks,

Sandro

User Experience:

After some time the application was running, it started becoming slow, though the CPU load was low. The user experienced a latency in terms of responsiveness of the component.

Analysis on Code Cache:

After some research and internal discussions with colleagues, I started concentrating on the JIT compilation and the Code Cache:

I performed a parallel test (for comparison) with both jre 1.6 and jre 1.7.

Here are the jvm flags used for the test:
-XX:ReservedCodeCacheSize=48M (default)

-XX:+UseCodeCacheFlushing (default only in jdk 1.7)

Below you can find a test executed with jre 1.6 and jre 1.7:

CodeCache.png

Note: I have seen that in jre 1.7, after sometimes the code compilation starts again (after reaching a very low level, for example 3MB)

JRE 1.8: this issue is not experienced in jre 1.8, in which the flushing algorithm seems to be changed: the flushing starts before getting the code cache full.

jdk8_CodeCache.png

Temporary solution:

A workaround for this problem would be increasing the Code Cache size and be sure the Code Cache flushing does not happen . In my application the Code Cache size average seems to be 55MB, so I solved by setting it to 80MB.The following JVM option has been used:

-XX:ReservedCodeCacheSize=80M

Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Sep 19 2014
Added on Jul 24 2014
2 comments
4,910 views