|
Tips for Using Heap Window and Memory Profiler to Find Memory Leaks
I'd remembered reading a blog posting that Brian Duff made some time back about how to use the JDeveloper 10g "Heap Window" while debugging but I'd never had a need to put it into practice until this week.
Googling for "jdeveloper memory leak duff" found me the article: Finding Memory Leaks with JDeveloper's Debugger
I was just blown away by how powerful this feature of our product was. At any time while debugging, you can:
- Press the debugger "Pause" button
- Press the debugger's "Garbage Collect" button a few times to get the VM to do its cleanup
- Bring up the debugger's "Classes" window and find the class you're interested in studying
- Right-mouse "Show in Heap Window" on that class and you can see every instance of that class that's still hanging around in the heap.
- Right-mousing on one of those instances and doing "Show Reference Paths" shows you a list of all the different things that have an outstanding reference to this instance in question, preventing it from being GC'd. These are listed in a depth-of-reference order, so the ones at the top of the list are the ones with the most direct reference to your un-GCable object.
- Right-mousing on any of those referring instances (typically the first one in the list), you can say "Expand Reference Path" and it expands the tree of all members until it gets to the place where the reference to your object is held, and shows that to you in bold to make it easy to see.
That's a huge time saver for debugging these kinds of issues. One additional tip that our debugger guru passed on to me yesterday regarding this feature is that while sitting there in the Heap window, you can right-mouse on the member holding the reference and pick "Modify Value" and set the value to Address 0 (a null reference). Then press the Garbarge Collect button and watch as the Heap Window updates to show what references are still left that are keeping your object pinned in the heap. (Note: she said that this might sometimes cause the program to error out, but when I tried it it worked for me!)
The JDeveloper Memory Profiler is also helpful if you're not sure which objects might be getting leaked. Inside your project properties dialog, there is a memory profile panel where you can set whether it used automatic sampling, or manual sampling (taking a sample only when you click on the little "camera" icon) to create "before" and "after" images of the memory usage. JDeveloper then shows you statistics about counts and sizes and differences between one snapshot and another which can help narrow down the culprit. Also, in that same Memory Profiler dialog, there is an "include" and "exclude" list so you can dramatically reduce the amount of classes or packages that you want to focus your attention on. Super helpful as well.
It is important to know that JDeveloper debugger features sophisticated filtering so that you can filter the classes and members you want to see and hide to reduce to the minimum what you have to "wade" through in the data window while debugging. Just do a right-mouse "Edit Filters..." and you can control virtually everything about simplifying your view of the world (even if only temporarily).
|
