OpenJDK Draft Plan Aims to Reduce JVM Code Cache Fragmentation and Boost Application Performance
A draft JDK enhancement proposal within the OpenJDK community seeks to significantly improve Java application performance by introducing a “hot” code heap alongside the segmented code cache. This innovative approach aims to tackle two key challenges: reducing application execution time and minimizing fragmentation in the JVM’s code cache.
The proposal suggests extending Java’s compiler control capabilities to identify and designate certain methods as “hot,” meaning they are frequently executed and thus eligible for compilation into the hot code heap. This segregation of hot code aims to streamline its storage, reducing fragmentation within the code cache and optimizing the performance impact of scattered compiled code.
Based on earlier concepts from Java Development Kit 9, released in 2017, the hot code heap builds upon ideas surrounding segmented code caches and compiler control mechanisms. Its development is driven by the recognition that scattered hot code can significantly degrade performance, especially in environments where large volumes of code are frequently compiled and executed.
Central to the proposal is the acknowledgment that CPUs can incur penalties when executing scattered code, particularly if the code cache becomes excessively fragmented. Traditional solutions like large pages may not effectively mitigate these issues, making a focused approach like the hot code heap crucial for improving performance under such conditions.
Moreover, the proposal underscores the importance of profiling information to accurately identify and optimize hot code segments. By enhancing the compilation policy for hot code and implementing more aggressive code cache management strategies, the proposal aims to further enhance overall JVM performance.
While not yet earmarked for a specific Java release, the hot code heap proposal could potentially feature in future updates, with JDK 23 identified as a potential target. However, the timeline for implementation may vary based on community feedback and technical feasibility, ensuring robust integration without compromising Java’s stability and compatibility.
The CPU itself imposes penalties for executing large amounts of scattered code, the proposal states. On systems where this problem is significant, it cannot be solved by other means, such as large pages. The degree of the slowdown depends on the amount of hot code, the sparseness of that code, and the processor type.
The proposal also emphasizes that not all compiled code is called frequently all the time and that co-locating hot code using profile information can boost performance. It also is possible to enhance compilation policy for hot code for better performance and to perform more aggressive sweeping of colder code to reduce code cache.