1. Java Performance on z/OS: A Report From the Front Lines CMG2005 Craig Hodgins Paper 5047 Session 332

2. CMG2005 A Brief History of Java Why Java Matters on the Mainframe An Overview of Java for Mainframers Review of Two STROBE Measurements JVM CPU JITC CPU JAVAJIT CPU ZIP files Java CPU Overhead (logging, security) Java Methods Summary Agenda

3. CMG2005 A Brief History of Java 10 years old Developed at Sun Microsystems as an embedded language for household appliances Redesigned to work with cable TV Language of choice for the Internet Still used as an embedded language

4. CMG2005 Why Java Matters on the Mainframe IBM developed WebSphere Application Server Enables organizations to utilize Java applications under z/OS Java is frequently the biggest consumer of CPU in a WAS environment Java is replacing COBOL as the language of choice But Java consumes 5 to 10 times more CPU than COBOL does for the same function

5. CMG2005 What is Java? Java is not… … a 1960’s reference to coffee … an island in the Pacific

6. CMG2005 What is Java? An object-oriented language Objects (bank account) Methods (withdrawal, deposit, open, close)

7. CMG2005 Components of Java Applets are Java programs running in a web browser Servlets are Java programs running in a web server JavaServer Pages (JSPs) display data to the user Enterprise Java Beans (EJBs) are server- side components that contain business logic Most of these components can execute under WAS on z/OS

8. CMG2005 Java / COBOL Java method contains multiple statements and is like a COBOL CSECT Java class contains multiple methods and is like a COBOL load module A Java package is an organizational tool similar to a high level qualifier or a Windows directory A Java CLASSPATH is similar to a library in z/OS or a PATH in Windows

9. CMG2005 The Java Call Stack As the Java application executes, memory is allocated in the Java Call Stack Frames are pushed and popped on and off the stack as the methods are invoked The state of the Java Call Stack reflects the chain of methods from the initial method called to the current method that is executing

10. CMG2005 Call Stack top  com.compuware.PayRoll.main(void)  com.compuware.Payroll.CalculateSalary(…)  com.compuware.Payroll.ComputeOverTime(…)  java.lang.String.CharAt(…)  java.lang.String.toLowerCase(…) com.compuware.PayRoll.main(void)  com.compuware.Payroll.CalculateSalary(…)  com.compuware.Payroll.ComputeOverTime(…)  java.lang.String.CharAt(…)  java.lang.String.toLowerCase(…) toLowerCase CharAt ComputeOverTime CalculateSalary main toLowerCase CharAt ComputeOverTime CalculateSalary main Java Application Java Call Stack bottom  The Call Stack is an area of memory that maintains the order in which Java methods are executed When a method is invoked, a “Stack Frame” is “pushed” to the top stack of the stack When the method is completed, it is “popped” off the stack

11. CMG2005 WAS Architecture

12. CMG2005 CPS 40.57% Wait 59.43% Session duration 15 minutes CPU 5 min

13. CMG2005 Libjvm 29.70% Java 41.55%

14. CMG2005 JVM CPU Usage JVM is the environmental code Java engine that manages the components Usually consumes around 25-35% of the CPU If JVM CPU seems high: upgrade to a newer release apply latest maintenance

15. CMG2005 Libjitc 4.13%

16. CMG2005 JITC CPU Usage Java is interpreted by default IBM introduced a Just-in-Time Compiler that will compile methods on the fly MMI (Mixed Mode Interpreter) parm sets threshold that must be reached before compilation Forces distribution of compilation overhead…

17. CMG2005 JITC CPU Usage … when the JVM initiates, thousands of methods are executed Significant overhead all at once as methods are compiled Possible that it may take longer to initiate the JVM than run the application

18. CMG2005 JITC CPU Usage JIT on, MMI on (default) JVM will start relatively quickly (interpreted) and runtime performance will improve over time (JITC) JIT off, MMI off JVM will start quickly, but runtime execution will be slow (interpreted) JIT on, MMI off (forces compilation only) JVM will start slowly but runtime will be optimized

19. CMG2005 JAVAJIT CPU Usage JAVAJIT is the CPU consumed by the total compiled methods in the measurement

20. CMG2005 JAVAJIT 16.17% Libjitc 26.51%

21. CMG2005 JAVAJIT 50.01% Libjitc 4.13%

22. CMG2005 Libzip 5.54%

23. CMG2005 ZIP Files ZIP files are used to combine multiple class files into one file to reduce I/O overhead, load time, or file transfer time 5.54% may be acceptable (must determine your own benchmarks) Recommendation is to use uncompressed ZIP or JAR files to reduce compression overhead

24. CMG2005 Class Loading JVM searches the directories in the order they are listed in the CLASSPATH environment variable Class loader has two modes Application mode: search first within the application directory and then the IBM directory J2EE mode: search first in the IBM directory and then the application directory

25. CMG2005 Class Loading Paths should be reordered so that the most used libraries are found first Package the classes in the order in which they are loaded by the application Do not add unnecessary class files to avoid large files and extra memory usage

26. CMG2005 JAVA CPU Overhead Computers make it easier to do a lot of things, but most of the things they make it easier to do don’t need to be done. Andy Rooney

27. CMG2005 JAVA CPU Overhead Hierarchical method invocation requires extra processing for each method call to determine the target (build the call stack) Keep current on JVM releases and maintenance levels Security checks consume CPU (eg 7.6%) Tuning security is a trade-off between performance and integrity

28. CMG2005 JAVA CPU Overhead Logging always degrades performance Documented techniques to have logging turned on in test but turned off in production Different levels of logging can be customized

29. CMG2005 Rtrim 3.41%

30. CMG2005 RTRIM Method Inhouse routine to strip off rightmost bytes of data Developer thought it may be possible to rewrite the application such that RTRIM was not required

31. CMG2005 The Cost of the RTRIM Method Measurement was for 15 minutes, CPU time was 5 minutes: WAS CPU per hour = 5 minutes x 4 = 20 minutes WAS CPU per year =.3 X 8760 = 2628 hours RTRIM CPU per year = 3.41% of 2628 = 89 hours Total dollar cost of RTRIM per year = $550.00 X 89 = $48,950.00 May run in other applications and multiple WAS

32. CMG2005 MicroValidator 1.65% validateField 0.59%

33. CMG2005 Validate Method Some kind of validation process Can it be done on another platform? Some less expensive way of validating?

34. CMG2005 String 3.32% StringBuffer 1.10%

35. CMG2005 Text Processing (Strings) Strings are immutable Cannot be modified A new StringBuffer object will be created under the covers A new String object is returned via the toString method Beware of text processing in loops

36. CMG2005 Text Processing (Strings) Several methods generate new instances of objects: concat replace substring trim

37. CMG2005 Text Processing (Strings) StringBuffers are modifiable Use them to avoid creating temporary String objects Possible alternative solution: use character arrays instead of strings

38. CMG2005 toUpperCase toLowerCase

39. CMG2005 Text Processing (Strings) Why are we using these methods? Can they be done on another platform? Is there a better way?

40. CMG2005 Text Processing (Strings) When parsing a string, pass the length as a parm Otherwise Java must make many calls to the String.length method Use char arrays rather than using String.charAt

41. CMG2005 Summary JVM – keep up with maintenance JITC – optimize MMI parm ZIP – use judiciously Methods – Always question things: Ask “Why?” Ask “How?” Ask “Is there a better way?”

42. CMG2005 Summary The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth. Niels Bohr, Quantum Physicist Common sense is not very common – Latin proverb

43. CMG2005 Further Reading Diagnostics Guide JDK 1.3.1 (SC34-6200-02) Java Performance Tuning, Jack Shirazi www.javaperformancetuning.com Other books, other websites

44. CMG2005 No matter what kind of system we have or what the application is, nothing in computer work seems to go as quickly as we think it should. The faster computers move, the more they try our patience. We get a more powerful machine and it still doesn’t process fast enough to satisfy us. Simple as a task might seem to finish, it inevitably takes longer than predicted. There’s always one more thing to get right, to tweak, to test again. Zen Computer Final Thought

45. CMG2005 Thank you Craig.hodgins@compuware.com