Java Magazine, March/April 2016

ORACLE COM JAVAMAGAZINE MARCH APRIL 2016 27 inside java file detailing the instances to be created and wired up and defines the classes to be loaded This means that Spring applications go through two phases of class loading first the phase of loading the classes needed to start the bootstrapping and then a second phase that occurs when the application classes are typically loaded From the point of view of JIT compilation this is important because the Spring framework uses reflection and other techniques to discover which classes to load and instantiate These framework methods are called heavily during application startup but then are never touched again after that If a Spring framework method is run enough to be compiled it is going to be of minimal use to the application It will marginally improve application startup time but at the price of using up a scarce resource If enough framework methods are compiled they can use up the entire code cache leaving no room for the application methods that we actually want to be compiled To solve this problem the JVM uses a system in which the values of counters decay over time In their simplest form the decay reduces the invocation counts for methods by 50 percent every 30 seconds This means that if methods are used only at startup their invocation counts will within a few minutes have decayed down to efectively zero This prevents the rarely used Spring framework methods from using valuable code cache space Which Switches Control Compilation and the Code Cache The following switches control compilation and the code cache XX PrintCompilation shows log entries for compilation and deoptimization events XX CompileThreshold n changes the number of times a method must be called before being compiled XX ReservedCodeCacheSize YYm sets the overall size of the code cache to be used XX UseCodeCacheFlushing allows a JVM to flush littleused code blobs this is on by default in Java 7 Update 4 and later How Do We Fix Applications Suffering from a Full Code Cache To identify a full code cache and resolve it first make sure the cache is a limitation That is always true in the event a compilation halted warning is issued You can check whether the size is too small and remediate the problem using these steps 1 Use XX PrintCompilation to output the methods that are actually being compiled 2 Wait until this reaches steady state 3 Repeat a few runs Check that the results set is stable 4 Try increasing the size of code cache doubling is often a good first step using XX ReservedCodeCacheSize If more methods are now seen to be compiled you can be sure that the original code cache was too small 5 Retest overall performance to ensure that increasing the code cache size hasnt harmed some other aspect of application performance Optimizations such as this have an important empirical aspect once you make a change you must measure its results carefully As this article demonstrates the first step is understanding what the JVM is doing so that you know what changes to try Ben Evans helps to run the London Java Community and represents the user community on the JCP Executive Committee learn more Oracles JVM Specification for Java SE 8