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