Updated (09/26/2014): In the latest JDK 8 release,[20] TieredCompilation is ON by default. Depending on platforms, default ReservedCodeCacheSize is bigger too. For example, on Linux 64-bit platforms, its default size is 240MB. |
Hotspot has two JITs named c1 (i.e., client JIT) and c2 (i.e., server JIT)[1,5,6]. The client JIT starts fast but provides less optimizations. So, it is used for GUI application. The server JIT starts more slowly but provide very good optimizations. The idea of tiered compilation is to get the best of both compilers, first JITs the code with c1 and then if the code is really hot to recompile it with c2.
The tiered server runtime is enabled with the following Hotspot VM options:
- -server -XX:+TieredCompilation
PrintCompilation
- -XX:+PrintCompilation [4]
66 4 n 0 java.lang.System::arraycopy (0 bytes) (static) 66 5 3 java.lang.String::hashCode (67 bytes) 67 1 3 java.lang.String::equals (88 bytes) 68 2 3 java.lang.String::charAt (33 bytes) 504 69 ! java.util.jar.Attributes::read (410 bytes) 522 70 java.util.jar.Attributes$Name::isValid (45 bytes) 522 69 ! java.util.jar.Attributes::read (410 bytes) made not entrant 864 69 ! java.util.jar.Attributes::read (410 bytes) made zombie
Without much ado, we will refer you to read [5] for detailed explanation of each field in the output. For our purpose, we are interested in finding out:
- How many methods have been compiled at the beginning of, say, 10 minutes?
- grep :: <logfile> | wc -l
since the compilation lines all have "::" in them. Based on this information, you can estimate what size of code cache size should be for better performance. You can also use this command line option along with instrumenting the benchmark to indicate when it has completed the warm-up period. For example, if you are observing -XX:+PrintCompilation output during the measurement interval, then benchmark has not reached JIT compiler steady state.
ReservedCodeCacheSize
- -XX:ReservedCodeCacheSize=256m
In our experiments, we have measured the performance of ATG CRM Demo application with different maximum code cache sizes. Here are our findings:
-TC 64M | +TC 64M | +TC 128M | +TC 256M | +TC 512M | +TC 1024M | |
Response Time (seconds) | 0.236 | Failed | 0.496 | 0.227 | 0.226 | 0.223 |
TC: Tiered Compilation
nnnM: Reserved Code Cache Size
Conclusion
Finally, be warned that options that are specified with
-XX
are not stable and are not recommended for casual use. These options are subject to change without notice[4].References
- Tiered Compilation
- See also: HotSpot Glossary of Terms
- PrintCompilation JVM flag
- Infrastructure for Tiered Compilation Support
- Java Hotspot VM Options
- About PrintCompilation
- JVM Runtime Compilers: -client or -server
- Java Tuning White Paper
- A Case Study of Using Tiered Compilation in HotSpot
- HotSpot VM Performance Tuning Tips (XML and More)
- Java Performance by Charlie Hunt, Binu John, David Dagastine
- All other performance tuning articles on XML and More
- Using JConsole
- How to Troubleshoot High CPU Usage of Java Applications? (XML and More)
- HotSpot: Using jstat to Explore the Performance Data Memory (XML and More)
- Understanding String Table Size in HotSpot (XML and More)
- HotSpot VM Performance Tuning Tips (XML and More)
- HotSpot Performance Option — SurvivorRatio (XML and More)
- All other performance tuning articles on XML and More
- JDK 7u40 (Java(TM) SE Runtime Environment: build 1.7.0_40-b43)
- Default values for linux-x64:
- ReservedCodeCacheSize: 50331648 {pd product}
- TieredCompilation: false {pd product}
- JDK 8: Revisiting ReservedCodeCacheSize and CompileThreshold (Xml and More)
- HotSpot Virtual Machine Garbage Collection Tuning Guide
- Garbage-First Garbage Collector Tuning
1 comment:
[7] Oracle link for Java Tuning White Paper : http://www.oracle.com/technetwork/java/tuning-139912.html
Post a Comment