Ensuring Performance In Java Development

1. Ensuring Performance In Java Development Steven Haines J2EE Architect and Evangelist Quest Software

2. Agenda • Speaker introduction • Performance challenges facing the Java Developer • Mastering object allocation dangers • Avoiding performance "Gotchas" in development • Why “Test Early, Test Often” is critical for your application’s success • Strategies for guaranteeing performance in development • Questions & Answers

3. Speaker Introduction • J2EE Architect and Evangelist for Quest Software • Author of Java 2 Primer Plus and Java 2 From Scratch • Co-Author of Java Web Services Unleashed • Java Host and columnist on InformIT.com (Pearson Education) • Java Instructor at the University of California, Irvine (UCI) and previously Learning Tree University (LTU) • Recruited as a J2EE architect in the “real world”

4. Performance challenges facing the Java Developer

5. Challenges In Java Development • Most Java problems are related to: • Memory usage • Algorithms & data structures • Execution environment

6. Mastering Object Allocation Dangers

7. Memory Safety in Java • Two main threats to Java memory efficiency • Loitering Objects • Object Cycling • You have to understand the role of object references with respect to garbage collection in order to avoid these problems

8. Java Memory Management • As objects are created they’re stored within the JVM’s heap • They can only be removed in a JVM-controlled garbage collection • Removes objects that are no longer needed • Undecidable in general, so Java uses an approximation... • Removes objects that are no longer reachable (accessible to the program at the beginning of a garbage collection cycle) • The reachability test starts at the heap’s root set

9. The Root Set • Set of foundational object references within your application • static reference fields within class definitions • Local reference variables within the method frames of each thread stack • The contents of the JVM’s root set changes dynamically • As threads enter and exit methods, local reference variables come into and go out of scope (enter and leave the root set)

10. Dynamic Nature of the Root Set - 1 • Consider a single thread of execution... 1 public 2 class MyApp 3 { 4 static private MyAppmyApp = null; 5 6 static public 7 void 8 main( String[] args ) 9 { 10 myApp = new MyApp( ); 11 myApp.method1( ); 12 myApp.method2( ); 13 } Root Set: MyApp myApp String[] args

11. Dynamic Nature of the Root Set - 2 14 private void 15 method1( ) 16 { 17 FooObjectfooObj = new FooObject( ); 18 ... 19 } 20 21 private void 22 method2( ) 23 { 24 BarObjectbarObj = new BarObject( ); 25 ... 26 } 27 } Root Set: MyApp myApp String[] args FooObject fooObj

12. Dynamic Nature of the Root Set - 3 1 public 2 class MyApp 3 { 4 static private MyAppmyApp = null; 5 6 static public 7 void 8 main( String[] args ) 9 { 10 myApp = new MyApp( ); 11 myApp.method1( ); 12 myApp.method2( ); 13 } Root Set: MyApp myApp String[] args

13. Reachable Objects Heap Root Set

14. Garbage Collection andObject Reachability • Objects within the heap can be considered to be in one of two “states”: • Allocated • Exists within the JVM’s heap • Reachable • A path exists (directly or indirectly) from a member of the root set, through a sequence of references, to that object

15. Unreachable Reachable Root Set Object Reachability

16. Garbage Collection andObject Reachability At the beginning of a GC cycle, objects that are allocated but no longer reachable are reclaimed by the Garbage Collector

17. What is a “Memory Leak”in Java? • We can extend the set of object states to three: • Allocated • Exists within the JVM’s heap • Reachable • A path exists from a member of the root set, through a sequence of references, to that object • Live • From the intent of the application’s design, the program will use the object (meaning at least one of its public fields will be accessed and/or one of its public methods will be invoked) along some future path of execution

18. What is a “Memory Leak”in Java? C++ MemoryLeak Unreachable Reachable but not Live JavaMemory Leak Reachable and Live Root Set

19. “Memory Leaks” in Java • Impact can be very severe • Rarely a single object, but an entire sub-graph of objects • A single lingering reference can have massive memory impact (and a significant performance impact) • Overall process requires more memory than necessary • JVM’s memory subsystem works harder • In the worst case, your Java application will throw an OutOfMemoryErrorand terminate Unintentional reference

20. Eliminating Loitering Objects Strategies and Tactics

21. Reference Management • The key to effective memory management in Java is effective reference management • What undermines effective reference management ? • Awareness of the issue • Bad habits from C/C++ development • Class Libraries and Application Frameworks • Tool (IDEs and others) generated software

22. Reference Management:Improving the Software You Create • As a Java programmer, how can I effectively manage references within my software, and promote better reference management ?

23. Design for Reference Management • For each application-level use case, explicitly characterize: a. The life cycle of each object b. The interrelationships (nature and duration) between various objects

24. Implementation • Loitering objects often arise from simple coding oversights or omissions • Forgot to null-ify a reference variable • Failure to remove an object from an internal list • Use the heap analysis features within JProbe Memory Debugger to validate that your implementation adheres to your design

25. Avoiding Performance "Gotchas" in Development

26. Manifestation of J2EE Application Performance Problems • Low-Hanging Fruit • Inefficient Database Access • Excessive Calls to Remote Objects/Services • Trees Falling in the Forest • Cumulative effect of inefficient algorithms • Cumulative effect of unnecessary overhead

27. Double-Check SQL • Java developers are typically not expert SQL developers • Use tools like SQL Navigator and Quest Central to help you if you’re doing EJB development • Understand the fine-tuning of joins and join orders • Understand what is and is not indexed in your database • Ask a DBA, if you can

28. Excessive EJB-Related SQL Execution • Simply accessing an Entity EJB can result in two SQL statement executions • Finder • Load • Use CMP instead of BMP • Accessing a collection of n entities will result in n + 1 SQL statement executions

29. Avoid Entity EJBs for Read Only Data Access • Unnecessary transactional overhead • Potential remote call overhead • Complex code for simple joins • Use the Fast Lane Reader pattern as your guide if your clients can handle potentially stale data (often the case)

30. Strategies for Guaranteeing Performance In Development

31. Working Together To Define Performance • Members of the development and operations group must both be involved in the setting of performance guidelines for the application • Guidelines should be reasonable, and include a measure of the extent to which they are flexible • I.e. Login should be under 2 seconds per user with no more than a 20% variance above this during peak usage

32. Manifestation of J2EE Application Performance Problems • Within The J2EE Application • End User Response Time • Within The Environment • Application Server Resource Utilization • JVM Heap Utilization • System Resource Utilization • Database Utilization • Network Activity

33. Test Throughout The Cycle • When developers are unit-testing their code, they should also perform memory and performance tests • Watch for memory leaks and memory efficiency • Performance testing is just to spot any egregiously slow areas in the code, not to match SLAs • These tests should be repeated as the individual elements in the application are brought together at each milestone

34. Test Early, Test Often • Testing throughout the cycle has the following benefits • As each developer looks for memory leaks in their own code they learn from their mistakes • The application will be built on a solid foundation of reliability and performance • The QA cycle will be smoother and shorter • The development team will not need to get involved in QA and production problems as often so they can concentrate on development

35. Dealing With Outsourcing • The reports that can be generated from tools like JProbe will show how the quality of the application is progressing • In most cases it will be easy to compare the quality of code produced in-house versus the quality of code returning from out-sourcers

36. Dealing With Outsourcing • A tool like JProbe Memory Debugger should be run against all out-sourced code before it is released to QA • This ensures that you don’t burn valuable QA cycles on an unstable build (memory leaks often show up later in testing if you don’t use a memory debugger first)

37. The JProbe Suite

38. Performance Tuning Tools JProbe Memory Debugger JProbe Profiler JProbe Threadalyzer JProbe Coverage Weekly Webcast: http://java.quest.com/webinars/jprobe/

39. Thank you http://www.quest.com