Did you specify any extra JVM parameters to reach the state of full CodeCache? Some comments on the internet indicate this happens if you specify too low "-XX:CompileThreshold" and too much bytecode gets compiled by HotSpot very early.
when the following warning was seen:
VM warning: CodeCache is full. Compiler has been disabled.
In this article, we will look at tuning CompileThreshold and ReservedCodeCacheSize in JDK 8.
CompileThreshold
By default, CompileThreshold is set to be 10,000:
intx CompileThreshold = 10000 {pd product}
As described in [2], we know {pd product} means "platform-dependent product option". Our platfrom is linux-x64 and that will be used for this discussion.
Very often, you see people setting the threshold lower. For example
-XX:CompileThreshold=8000Why? Since the JIT compiler does not have time to compile every single method in an application, all code starts out initially running in the interpreter, and once it becomes hot enough it gets scheduled for compilation. To help determine when to convert bytecodes to compiled code, every method has two counters:
- Invocation counter
- Which is incremented every time a method is entered
- Backedge counter
- Which is incremented every time control flow moves from a higher bytecode index to a lower one
The threshold used for the invocation counter is called the CompileThreshold, the backedge counter uses a more complex formula derived from CompileThreshold and OnStackReplacePercentage. So, if you set the threshold lower, HotSpot compiles methods earlier. And, in some cases, that can help the performance of server codes.
ReservedCodeCacheSize
A code cache is where JVM uses to store the native code generated for compiled methods. As described in [3], to improve an application's performance, you can set the "reserved" code cache size:
- -XX:ReservedCodeCacheSize=256m
What's New in JDK 8?
We have seen people setting the following JVM options:
- -XX:ReservedCodeCacheSize=256m -XX:+TieredCompilation
- -XX:CompileThreshold=8000
In JDK 8, it chooses the following default values for linux-x64 platforms:
bool TieredCompilation = true {pd product}
intx CompileThreshold = 10000 {pd product}
uintx ReservedCodeCacheSize = 251658240 {pd product}
When tiered compilation is enabled, two things happen:
- CompileThreshold is ignored
- A bigger code cache is needed. Internally, HotSpot will set it to be 240 MB (i.e., 48 MB * 5)
- -XX:ReservedCodeCacheSize=256m -XX:+TieredCompilation
- -XX:CompileThreshold=8000
Noted that “reserved” code cache is just an address space reservation, it does not really consume any additional physical memory unless it’s used. On 64-bit platforms, it doesn’t hurt at all to set a higher value. However, if you have set cache size to be too small, you will definitively see the negative impact on your application's performance.
Acknowledgement
Some writings here are based on the feedback from Igor Veresov and Vladimir Kozlov. However, the author would assume the full responsibility for the content himself.
References
- VM warning: CodeCache is full. Compiler has been disabled.
- HotSpot: What Does {pd product} Mean? (Xml and More)
- Performance Tuning with Hotspot VM Option: -XX:+TieredCompilation (Xml and More)
- A Case Study of Using Tiered Compilation in HotSpot (Xml and More)
- Useful JVM Flags – Part 4 (Heap Tuning)
- g1gc logs - Ergonomics -how to print and how to understand
- G1 GC Glossary of Terms
- Learn More About Performance Improvements in JDK 8
- HotSpot Virtual Machine Garbage Collection Tuning Guide
- Other JDK 8 articles on Xml and More
- Tuning that was great in old JRockit versions might not be so good anymore
- Trying to bring over each and every tuning option from a JR configuration to an HS one is probably a bad idea.
- Even when moving between major versions of the same JVM, we usually recommend going back to the default (just pick a collector and heap size) and then redoing any tuning work from scratch (if even necessary).
No comments:
Post a Comment