In January 2010 we submitted a new change to OpenJDK to overcome a long standing problem in the HotSpot JVM, that is that there was no mechanism in the JVM to recover if the code cache of compiled Java methods became full. The only course of action was to shut off the JIT compiler in both client and server versions. Nothing further would get compiled and depending on the application behavior it could lead to a substantial degradation of the application performance. The Hotspot JVM code cache has a fixed upper size and can be controlled by -XX:InitialCodeCacheSize=n and -XX:ReservedCodeCacheSize=n. Our change introduces a way for the code cache to be selectively cleaned based on application behavior which should allow the application’s hot methods to remain compiled and continue to run at full speed.

We noticed that in some applications, for example application servers with hot redeployment, it may be that the old web app classes would never get unloaded, which led to the compiled java methods never getting unloaded even though they might never be called again. This could lead to the code cache becoming completely full. Based on those observations we decided to target to unload the oldest compiled Java methods first, allowing the newest redeployment version to run at full speed.

Our solution, developed in coordination with the Sun/Oracle Hotspot team, is to attempt to unload the oldest half of the compiled Java methods when the code cache becomes full. If any method marked for removal actually got invoked by the application immediately following the cleaning step, it would be kept alive and go back to the normal state. If any methods marked for removal are not called within a short period following the cleanup step, they will be removed using existing mechanisms in the JVM. This process will clear up space in the code cache so compilation can continue.

This technique allows the program to continue normal operation, keeping the JIT compilers operating normally, and the application continues to run at full speed with basically no noticeable effect on the performance of the application. This new feature is currently off by default, available by the option -XX:+UseCodeCacheFlushing. It is available in the latest OpenJDK hotspot mercurial source repository, in OpenJDK 7 build83, see: https://jdk7.dev.java.net/, and may appear soon in an official JDK 6 version.

We hope this new feature will help to provide greater performance and uptime for long running java applications. Please try it out and give feedback to the mailing list, hotspot-compiler-dev, at http://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev.

Eric Caspole is a member of the Java Labs team at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.