JProbe Memory Debugger Tips and Tricks - PowerPoint PPT Presentation

1 / 56
About This Presentation
Title:

JProbe Memory Debugger Tips and Tricks

Description:

Live ... Live 'Memory leak' in Java. Memory leak in C/C (handled by JVM's GC) Loitering Objects. The term 'Memory Leak' has a lot of historical context from ... – PowerPoint PPT presentation

Number of Views:118
Avg rating:3.0/5.0
Slides: 57
Provided by: TAvn
Category:

less

Transcript and Presenter's Notes

Title: JProbe Memory Debugger Tips and Tricks


1
JProbe Memory Debugger Tips and Tricks
  • Leonard Slipp
  • Quest Software

2
Goals of Our Session
  • Preparing Your Investigation
  • Object Cycling Analysis
  • What it is and why its important
  • Investigative Setup
  • Interpreting Runtime Information
  • Loitering Object (Memory Leak) Analysis
  • What it is and why its important
  • Investigative Setup
  • Interpreting Runtime Information
  • Snapshot Analysis

3
Memory Safety in Java
  • Memory safety was a key aspect in the design
    of...
  • The Java Language
  • Absence of any form of pointer arithmetic
  • Can not directly reclaim object memory
  • And the Java Virtual Machine (JVM)
  • Bytecode instruction set
  • Runtime checks (array bounds, reference casts)
  • Garbage collection

4
Memory Safety in Java
  • Entire classes of memory-related problems were
    eliminated
  • Buffer overruns
  • De-referencing stale pointers
  • Memory leaks
  • However subtle memory management issues remain
    that can easily undermine the performance of your
    application
  • Object Cycling
  • Loitering Objects (Javas Memory Leaks)

5
Preparing Your Investigation
6
Tip Adopt a Use Case-centric Investigative
Approach
  • As an investigator, you want to be very
    comfortable with the users view of your
    application
  • Why Use Case-centric Investigation ?
  • Centers investigation on the users experience
    and how the symptoms of the underlying flaw
    affect them
  • Focus on the execution path of the use case, and
    how the underlying implementation is flawed

7
Our Example Application
  • A servlet-based J2EE application with a single
    use case
  • Select a company on the applications main page
  • Other applications
  • Sign on
  • Search catalog
  • Add to virtual shopping cart
  • Go to the virtual check out
  • etc..

8
Our Example Application (Cont)
  • Servlet invocation
  • Reads the historical price information from an
    XML file
  • Reformats the data into an HTML table which is
    then returned to the browser and rendered

9
Tip Ensure Youre Confident with the Underlying
Architecture
  • You need to have a comfortable literacy with the
    internal architecture and design goals of the
    application
  • Names of all the packages
  • Names of key classes and methods
  • For each of the application use cases, ensure you
    are familiar with
  • The principle methods invoked along that
    execution path
  • Any attempts at optimizations (caching,
    pooling, etc -)
  • If youre not familiar with the underlying design
    and its implementation, the investigation will be
    much more difficult

10
Tip Ensure Youre Confident with the Underlying
Architecture
  • In our example program
  • One Package
  • com.acme.
  • Four Principle Classes/Interfaces
  • com.acme.StockServlet
  • com.acme.StockDataJDOM
  • com.acme.PageCache
  • com.acme.CachedPage
  • The program uses a Most Recently Used (MRU)
    caching algorithm that retains the last 3 most
    recently requested pages

11
Tip Organize Your Workspace for Fluid
Investigation
  • Tile the UI of your application along with the
    UI of JProbe so everything is visible
  • Eliminate the effort of constantly repositioning
    and resizing dialog boxes
  • Focus your attention on the investigation, not on
    repositioning dialogs

JProbe UI
Application UI
12
Object Cycling Analysis
13
Object Cycling
  • One of the principal causes of performance loss
    in Java is the excessive creation of short life
    cycle objects
  • Performance loss is due to...
  • Memory allocation within the JVM heap
  • Object initialization via chain of constructor
    calls
  • Enhanced garbage collection activity
  • As a performance investigator, identify those
    methods in your application-level that are object
    cycling
  • They are your first candidates to examine for
    refactoring to improve performance

14
Object Cycling AnalysisInvestigative Setup
  • Within the LaunchPad
  • Enable Run Garbage Monitor During Use Case
  • Enter an asterisk () in the Filter on Package,
    Class or Method column of the first line in the
    Filter table
  • You want to see the entire heap contents
  1. Then press

15
Object Cycling AnalysisRuntime Information
  • Within the Runtime Heap Summary, before you
    select Start Use Case
  • Select the Garbage Monitor tab, and
  • Enter the fully qualified set of methods
    package.class.method to track allocations from
  • com.acme..

package
class
methods
16
Object Cycling AnalysisRuntime Information
  1. Within the Runtime Heap Summary, press Start Use
    Case
  2. Then, within your applications UI, begin the use
    case
  • In this case, well simply select a stock from
    the list

17
Object Cycling AnalysisRuntime Information
  • As GCs within the JVM occur, Garbage Monitor will
    indicate
  • The type of objects reclaimed
  • The methods that they were allocated from
  • When the use case completes, press Finish Use Case

e
18
Object Cycling AnalysisRuntime Information
  • When Finish Use Case is pressed, Garbage Monitor
    provides a final update to its table
  • Examine the top couple of lines in the table
  • The doGet() method in com.acme.StockServlet
    object cycles through 2,298 StringBuffers just to
    service 1 request !

19
Loitering Object Analysis(Memory Leaks)
20
What is a Memory Leak in Java ?
  • Memory leaks (as traditionally defined in C/C)
    cannot occur in Java
  • That memory is reclaimed by the Garbage Collector
  • However, Java programs can still exhibit the
    macro-level symptoms of traditional memory leaks
  • Heap size seemingly grows without bounds
  • Occurs when objects that have outlived their
    usefulness to the application remain within the
    heap through successive garbage collections

21
JVM Runtime Data Areas
Heap
  • Heap
  • The common memory pool where all objects and
    arrays are stored
  • Thread Stack(s)
  • One stack per thread of execution
  • Each stack consists of a series of method frames
    (one per called method) which contain the method
    arguments and return value, the local variables
    within the method and a bytecode operand stack
    for intermediate results
  • Method Area
  • Maintains the data structures for each loaded
    class in the JVM

Thread Stack
...
Thread Stack
JVM
Method Area
(Java program) executing within the JVM
(Java program and JVM) executing within the OS
22
Java Memory Management
  • As objects are created within a running Java
    program, theyre stored within the JVMs heap
  • Central to Javas memory management subsystem is
    the notion of 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 heaps root
    set

23
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 JVMs 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)

24
Dynamic Nature of the Root Set - 1
1 public 2 class MyApp 3 4 static private
MyApp myApp 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
25
Dynamic Nature of the Root Set - 2
  • 14 private void
  • 15 method1( )
  • 16
  • 17 FooObject fooObj new FooObject( )
  • 18 ...
  • 19
  • 20
  • 21 private void
  • 22 method2( )
  • 23
  • 24 BarObject barObj new BarObject( )
  • 25 ...
  • 26
  • 27

Root Set MyApp myApp String args
FooObject fooObj
26
Dynamic Nature of the Root Set - 3
1 public 2 class MyApp 3 4 static private
MyApp myApp 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
27
Reachable Objects
  • Elements within the root set directly refer to
    objects within the heap of the JVM
  • Reference variables within those objects refer to
    further objects within the Heap (indirectly
    reachable from the Root Set)

28
Reachable Objects GC
  • At the beginning of a GC cycle, objects within
    the heap can be considered to be in one of two
    progressive states
  • Allocated
  • Exists within the JVMs heap
  • Reachable
  • A path exists (directly or indirectly) from a
    member of the root set, through a sequence of
    references, to that object

29
Reachable Objects GC
Allocated
Reachable
30
What is a Memory Leak in Java?
  • Lets extend the set of object states to three
  • Allocated
  • Exists within the JVMs heap
  • Reachable
  • A path exists (directly or indirectly) from a
    member of the root set, through a sequence of
    references, to that object
  • Live
  • From the intent of the applications 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

31
What is a Memory Leak in Java?
Allocated
Reachable
Live
32
Loitering Objects
  • The term Memory Leak has a lot of historical
    context from C/C and it doesnt accurately
    describe the problem as it pertains to Java
  • New term Loitering Object or Loiterer
  • An object that remains within the Heap past its
    useful life to the application
  • Arise from an invalid reference that makes the
    object reachable to the GC

33
Loitering Objects
  • 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
  • JVMs memory subsystem works harder
  • In the worst case, your Java application will
    throw an OutOfMemoryError and terminate

Unintentional reference
34
Reference Management
  • The key to effective memory management in Java is
    effective reference management
  • What undermines effective reference management ?
  • Lack of awareness of the issue
  • Bad habits from C/C development
  • Class Libraries and Application Frameworks
  • Ill-defined reference management policies
  • Encapsulate flawed reference assignments
  • Tool (IDEs and others) generated software

35
Heap Investigation Strategy
  • You need a structured and disciplined approach to
    identify loitering objects systematically
  • Ensure that the underlying implementation adheres
    to the intent of your design
  • Based on classic scientific testing
  • Establish a hypothesis (what you expect to see)
  • Design and run an experiment to prove your
    hypothesis
  • Compare the experimental results against your
    hypothesis
  • Resolve the differences (if any)

36
Structure Your Hypothesis and Experiments Around
Use Cases
  • Focus on the Use Case-centric approach
  • Your hypothesis consists of the set of objects
    you expect to persist at the end of your use case
    (which you know from your architectural design)
  • Use Memory Debuggers Start Use Case and Finish
    Use Case features to define your use case

37
Loitering Object AnalysisInvestigative Setup
  • Within the LaunchPad
  • Disable Run Garbage Monitor During Use Case
  • Enter an asterisk () in the Filter on Package,
    Class or Method column of the first line in the
    Filter table
  • You want to see the entire heap contents
  1. Then press

38
Loitering Object AnalysisRuntime Information
  • Within the Runtime Heap Summary
  • The Instance Summary table (below the Heap Graph)
    provides a detailed breakdown of the Heap
    contents at the leading edge of the Heap Graph

39
Loitering Object AnalysisRuntime Information
  • When you press Start Use Case
  • Two additional columns appear within the Instance
    Summary
  • Count Change
  • Memory Change
  • Use this information to gauge the net increate in
    objects as you exercise your use case

40
Loitering Object AnalysisRuntime Information
  • As you are testing your Use Case, filter the
    table to the classes within your implementation
  • Enter the fully qualified set of classes
  • com.acme.

41
Loitering Object AnalysisRuntime Information
  • The design intent of our application is that the
    3 MRU stock are cached (any older ones are
    disposed of)
  • Load 6 in sequence
  • Apple
  • Compaq
  • Dell
  • Gateway
  • Hewlett-Packard
  • IBM
  • Oh, No ! All 6 are being cached (the oldest 3
    are loitering)

42
Resolving Loitering Object Flaws
  • Loitering Objects represent either a design flaw
    or an implementation flaw within the application
  • How should applications be designed and
    implemented to avoid these flaws ?
  • Knowing how they can be avoided helps us
    investigate how they they arose in our application

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

44
Object Lifecycles
  • For each object required in your design to
    fulfill an application-level use case, you need
    to define
  • Its point of creation
  • The duration of its usefulness
  • The point at which it should be eliminated from
    the runtime environment

45
Object Lifecycles
  • In Java, creating an object within the runtime
    environment is an explicit act, while its
    elimination is an implicit one
  • Defining within your design the point when
    your object should be eliminated will help you
    validate the correctness of your subsequent Java
    implementation

46
Inter-Object Relationships
  • Objects establish relationships with one another
    as they collaborate to accomplish their goals
  • Examples
  • Composition (a has-a relationship)
  • Association (a uses-a relationship)
  • Relationship life cycles
  • Relationships are established, exist for a
    defined period of time and then are revoked
  • Relationships are based on Java references

47
Inter-Object Relationships
  • When designing methods that establish and revoke
    relationships, think Symmetry
  • If you define a method that establishes a
    relationship, ensure you define a method that
    revokes it
  • The Observer Pattern
  • subject.addObserver( Observer )
  • subject.removeObserver( Observer )

48
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
  • Difficult to detect, except in catastrophic
    situations
  • The Java Runtime Environment doesnt provide any
    insight

49
Reference Variable Scope
  • Three forms of reference variables
  • Class-based
  • Reference variables within a class definition
    that have a static attribute associated with them
  • Object-based
  • Non static reference variables within a class
    definition
  • Method-based
  • Reference variables defined within the scope of a
    method

50
Reference Variable Scope
  • Dont be concerned about assignments to
    method-based reference variables within methods
    of short execution time
  • Be attentive of assignments to class-based and
    object-based reference variables, and
    method-based reference variables within methods
    of long execution times

51
Loitering Object AnalysisSnapshot Analysis
  • When your press Finish Use Case, JProbe will take
    a Heap snapshot
  • Entire contents of the Heap at that time
  • Load the snapshot into the Heap Browser
  • View identical to the Instance Summary
  • S
  • Select the Class of loitering objects, and open
    the Instance Detail dialog

52
Loitering Object AnalysisSnapshot Analysis
  • The Instance Detail dialog
  • Select one of the oldest loitering objects
  • Travers the references within the heap determine
    which references are holding on to the loitering
    object

s
g
53
Finding the Culprit
  • Given that we know
  • The loitering object, and
  • That the flaw is either
  • Design-based (object or relationship), or
  • Implementation-based
  • Carefully explore the references leading to the
    loitering object
  • In our case, our MRU caching algorithm is failing
  • It adds to the cache, but it doesnt remove form
    it
  • Turns out to be a misunderstanding on the correct
    use of java.util.HashMap

54
Loitering Object AnalysisSnapshot Analysis
  • The Snapshot Difference dialog
  • Used to confirm that your fix indeed solved the
    problem (and quantifies the memory saved)
  • Select the heap snapshot with the loitering
    object as the baseline
  • Compare it to a Heap snapshot taken with the fix
    in place

55
Session Wrap-up
  • Memory management within Java is great
    technology, but dont let it lull you into a
    false sense of complacency
  • Adopt a Use Case-centric Investigation Strategy
  • Know Your Application
  • How its put together and its design intent
  • Integrate memory analysis as part of your ongoing
    development activity
  • Dont leave it until youre about to deploy to
    production

56
Questions ?
  • leonard.slipp_at_quest.com
Write a Comment
User Comments (0)
About PowerShow.com