Java on System z. IBM J9 virtual machine

Transcription

1 Performance, Agility, and Cost Savings: IBM SDK5 and SDK6 on System z by Marcel Mitran, Levon Stepanian, and Theresa Tai Java on System z Java is a platform-agnostic (compile-once-run-anywhere), agile, and flexible language. As such, Java has become a cost-effective language of choice for implementing business logic, e-business solutions and services, as well as IT infrastructures. When combining the cost/benefits of the IBM System z Specialty Engine Application Assist Processor (zaap) with the resilience and versatility of IBM s System z mainframe technology and IBM s powerful middleware portfolio (WebSphere Application Server, WebSphere Portal Server, CICS TS, IMS, DB2, and the JZOS Java Launcher and Toolkit), it is easy to see why adoption of Java on mainframes continues to be strong. Recently, with the IBM z1 processor providing up to double the throughput improvement for Java applications, zaaps continue to provide increased cost savings for Java applications running on System z. With the release of the SDK5 [1][4] and SDK6 products, IBM continues to demonstrate concerted investment in its Java technology for System z. IBM's SDKs are now powered by the IBM J9 virtual machine and IBM TR-JIT compiler across all JSE/JEE platforms, including IBM z/os and Linux for System z. This paper reviews highlights of the new J9/TR technology before diving into key System z exploitations, and specifically discusses improvements in JIT and garbage collection performance. More specifically, this paper begins by introducing IBM s J9 virtual machine, as the heart-and-soul of the Java runtime environment. It then discusses new garbage collection and the TR-JIT technology packaged with J9. Further discussion about z1 support, including BigDecimal/decimal floating-point, follows. IBM J9 virtual machine Performance, security, reliability, and serviceability remain the guiding forces for steering IBM s JVM technology. Having a robust, versatile, and extensible runtime environment forming the foundation of the JVM is a prerequisite to empowering IBM to bring the latest innovations and features of virtual machine technology to its customers in a timely and scalable manner. As such, the IBM J9 virtual machine is a clean-room runtime environment that was re-engineered with this purpose in mind. 28, IBM Corporation 1 Version: 1-Aug-8

2 J9 s pluggable class-library interface and well-defined platform exploitation layer make the J9 virtual machine a first-class runtime environment across more than 2 platforms. This breadth in platform exploitation ensures better stability and robustness for users while empowering IBM s SDK to easily move and share innovations across the embedded, desktop, and server spaces. As a result, features such as hot-code replace, full-speed debugging, and shared classes are now staples in the server space. Collecting garbage with J9 Garbage collection continues to be an important defining component of any Java runtime environment. Considerable effort typically goes into optimizing GC parameters to best meet pause-time and throughput requirements, providing scalability and shorter pause times. The J9 virtual machine comes packaged with a state-of-the-art new garbage collector that is equipped with parallel mark, sweep, and compact capabilities and provides four GC policies [3][8]. The default policy, called optthroughput, will delay garbage collection for as long as it can. This allows the application to run at optimal throughput until a garbage collection is absolutely required. When a collection does occur, the application pauses until the collection completes. This policy is well suited for applications that are designed around raw throughput and for which longer GC pauses are not a concern. This policy is typically a good starting point for tuning the GC. By starting concurrent collections while the application is still active, the optavgpause policy will trade off throughput in an effort to reduce pause times. The gencon policy is ideal for transactional-based applications in which many objects are short lived. By allocating new objects to a smaller area of the heap -- called a nursery -- and typically only collecting the nursery, this policy shows more frequent but very short-lived GC objects. The last GC policy is the subpool allocation policy, which is designed for enterprise-scale applications that have allocation rates that cause scalability issues running on very large multiprocessor machines. 28, IBM Corporation 2 Version: 1-Aug-8

3 TR-JIT The performance engine of any JVM is its just-in-time compiler. As such, SDK5 and SDK6 are powered by the TR-JIT, which is a fully loaded dynamic compiler. The TR-JIT performs a significant set of loop-based optimizations that target program hot spots. These optimizations can be combined with value profiling to version and specialize code paths that behave in predictable manners. Aside from providing a very powerful set of Java-based, OO-based, and traditional optimizations, TR-JIT is also designed for deep System z exploitation. For instance, a full-fledged list scheduler is used to optimally exploit super-scalar inorder System z pipeline [7]. Additionally, several special optimization phases have been added for System z. These include an idiom-recognition framework [6] for identifying high-level loops written in Java that map to complex instructions available on the architecture and provide very effective speedups for converting between various code pages. Additional optimizations exist for exploiting the rich set of memory-to-register instructions in the architecture, thus reducing register pressure in compiled code. There is also a special register-allocator, which was built to exploit consecutive even-odd register-pair assignment. By virtue of being a dynamic compiler, the JIT is fully aware and self-tuning for the hardware it is running on. This allows TR-JIT to fully exploit new hardware features such as long-displacement support on z99, extended immediate support on z9, and a significant set of new instructions on z1. In addition, TR-JIT is equipped with a complex compilation control system that uses sampling and feedback to trigger up to six different levels of compilation. Exploiting feedback-based recompilations to stagger the investment in compilation allows TR-JIT to focus and amortize compilation effort to best match the application code behavior. The TR-JIT also supports asynchronous compilations, minimizing runtime compilation overhead. JVM start-up Application start-up time continues to be an important performance attribute for many users running Java-based applications. Quick start-up of enterprise 28, IBM Corporation 3 Version: 1-Aug-8

4 environments such as WebSphere Application Server allows for agile deployment and management of servers and respective applications. Additionally, batch-based environments with short job steps see their performance dominated by JVM startup time. Class loading and JIT compilation represent the two largest costs for JVM start-up. Shared-classes support [2][5]in SDK5 allows classes to be loaded into shared memory so that future instances of the JVM can avoid the cost of reloading classes from disk. SDK6 also adds support for storing and relocating ahead-of-time (AOT) compiled code in the shared-class cache. To further improve start-up time for short-running applications, the JVM provides a special Xquickstart option. The -Xquickstart switch tones down the default compilation level more aggressively. In SDK6, this mode also uses AOT compiled code more aggressively. 64- to 31-bit performance As the footprint for Java applications continues to grow and the z/os private area approaches exhaustion, 64-bit SDKs are likely to become more heavily adopted. As a result, significant work has gone into reducing the overhead of using 64-bit SDKs. SDK5 includes several optimizations to reduce this overhead. For enterprise-scale applications, the increased pointer size puts significantly more pressure on the hardware s memory management unit (MMU). SDK6 SR1 provides a methodology for compressing 64-bit references for heaps that live below the 4 GB virtual memory bar, hence providing better cache-locality at the expense of increased pathlength. This trade-off is typically a win on hardware with higher clocked frequencies such as the z1. Additionally, support for large memory pages on z1 in SDK6 SR1 provides relief for the pointer bloat that results from moving to 64-bit SDK. The larger pages increase the effective addressability of the System z TLB2. z1 exploitation In February of 28, IBM released the new System z1 mainframe. The new processor provides significant speedup in hardware thread performance. Based on 28, IBM Corporation 4 Version: 1-Aug-8

5 lab measurements, the hardware speedup has translated to a noted 1.3x to 2x performance improvement for Java workloads when migrating to z1. In addition, SDK6 includes several new z1 features such as exploitation of more than 2 new assembly instructions provided by the new architecture, full support for 64-bit decimal floating-point hardware (via the BigDecimal class) for increasing the performance and accuracy of financial calculations, as well as tuning for the new micro-architecture and support for large pages. In combination with the hardware speedup, the performance improvements provided by the new SDK and the cost effectiveness of IBM Specialty Engine zaaps, Java on System z continues to be an attractive choice for many users. Performance The following charts display performance improvements based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user experiences will depend on considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here. z/os 1.9 Single-Threaded Perform ance (z1) Scores Normalized to SDK SDK SDK SDK5-31 SDK6-31 SDK SDK5-64 SDK6-64 s1 b k c s2 o t gmean Benchm ark 28, IBM Corporation 5 Version: 1-Aug-8

6 Figure 1. Seven single- threaded benchmarks normalized relative to SDK showing incremental performance improvements for newer releases and 64-bit SDKs. z/os 1.9 Multi-Threaded Benchmarks on z1 (BM1 and BM2) Relative Improvement Normalized to 1st Thread of BM1 SDK SDK BM1 SDK BM1 SDK5-31-BM1 SDK6-31-BM1 SDK6-31-BM2 Threads Figure 2. Two multi-threaded benchmarks (BM1 and BM2). BM1 results are normalized to the first thread of SKD SDK6 BM2 results are normalized for the first thread of SDK5-31. z/os 1.9 Multi-Threaded Benchmark SDK131- z99 vs SDK6-z1 Relative Improvement Normalized to 1st Thread of SDK131-z Threads SDK z99 SDK6-31-z1 28, IBM Corporation 6 Version: 1-Aug-8

7 Figure 3. Combined hardware and SDK improvements. SDK6-31 z1 scores as normalized to the first thread of SDK running on a z99. A 5.86x improvement in throughput is observed. SUSE1 Linux for System z 31/64-bit Multi-Threaded Benchmark (CR and LP) on z1 Relative Improvement Normalized to Throughput of 1st Thread of 64-bit Threads 31-bit 64-bit 64CR 64CR+LP Figure 4. Compressed references (CR) cuts the 31- to 64-bit throughput gap in half. The use of large pages (LP) in combination with compressed references reduces the 31- to 64-bit gap further. z/os 1.9 WebSphere Application Server-Trade Improvements 1.4 Relative Performance WebSphere Application Server 6.1/SDK5 vs. WebSphere Application Server 6./SDK Throughput Start-up Elapsed Time Start-up CPU Time Figure 5. SDK5 improves WebSphere Application Server-Trade throughput. SDK5 also decreases elapsed and CPU times during WAS start-up. 28, IBM Corporation 7 Version: 1-Aug-8

8 z/os 1.9 Start-up Time Improvements (z1) 1.2 Normalized Improvement default quickstart shareclass quickstart+shareclass HelloWorld javac Tomcat Benchm arks Figure 7. SDK6 improvements to start-up time using different combinations of -Xquickstart and -Xsharedclasses (includes AOT). Conclusion The adoption of Java on mainframes continues to grow. As such, IBM has invested heavily in its SDK technology on System z. With SDK5 and SDK6, the IBM JVM was re-engineered, providing a significant improvement in performance, security, reliability, and serviceability. As a testament to the value of IBM s investment, this paper demonstrates incremental performance and scalability improvements with each level of the SDK. When combining these improvements with the cost effectiveness of IBM Specialty Engine zaaps and thread speedup of new processors such as the z1, the ever-growing value proposition of Java on System z is undeniable. References [1] Bailey C. (26). Java technology, IBM style: Introduction to the IBM Developer Kit. 28, IBM Corporation 8 Version: 1-Aug-8

9 [2] Corrie B. (26). Java technology, IBM style: Class sharing. [3] Cummins H. & Persson, M. (26). Java technology, IBM style: Garbage collection policies, Part 2. [4] developerworks : Java technology ( [5] D. Inglis, M. Lut, K. Ma, M. Pirvu. Reducing Startup Costs of Java Applications With Shared Relocatable Code. 5th Workshop on Compiler-Driven Performance. IBM Centre for Advanced Studies Conference. October 26, Toronto, Ontario, Canada. [6] M. Kawahito, H. Komatsu, T. Moriyama, H. Inoue, T. Nakatani. A New Idiom Recognition Framework for Exploiting Hardware-Assist Instructions. Proceedings of the 26 ASPLOS Conference. p , December 26. [7] M. Mitran, J. Siu, V. Tang, A. Vasilevskiy. A framework for reducing instruction scheduling overhead in dynamic compilers. Proceedings of the 26 conference of the Center for Advanced Studies on Collaborative research. 26, Toronto, Ontario, Canada. [8] Persson M. (26). Java technology, IBM style: Garbage collection policies, Part 1. Trademarks IBM, CICS, DB2, IMS, System z, WebSphere, z/os, and z1 are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. 28, IBM Corporation 9 Version: 1-Aug-8

10 Other company, product, or service names may be trademarks or service marks of others. 28, IBM Corporation 1 Version: 1-Aug-8