Memory Analyzer Configuration

Well, analyzing big heap dumps can also require more heap space. Give it some more memory (possible by running on a 64-bit machine):

MemoryAnalyzer.exe -vmargs -Xmx4g

Alternatively, edit the MemoryAnalyzer.ini to contain:

-vmargs
-Xmx2g

For more details, check out the section Running Eclipse in the Help Center. It also contains more details if you are running on Mac OS X.

If you are running the Memory Analyzer inside your Eclipse SDK, you need to edit the eclipse.ini file.

The memory intensive parts is the parsing. Try parsing the heap dump from the command line. Once it has been parsed, it usually can be opened with less memory in the GUI.

The preference page is opened via a menu option. Window > Preferences

The preferences page allows various aspects of Memory Analyzer to be controlled. preferences page showing general options with DTFJ subpage
Keep unreachable objects
Objects that appear unreachable from GC roots are not discarded in an early stage of Memory Analyzer processing, but are retained for further analysis.
Hide the getting started wizard
Controls whether to display a wizard for leak suspects, top components after opening a snapshot.
Hide popup query help
Do not display the help panel underneath the query wizard, unless F1 or the help button is pressed.
Memory Analyzer > DTFJ Parser > Stack frames
Normally stack frames are just shown in the Thread overview and stacks query. This option allows stack frames to be treated as objects which are then visible like any other Java object in a Memory Analyzer view.
Normal
Stack frames are just shown in the Thread overview and stacks query.
Only stack frames as pseudo-objects
Stack frames are of type <stack frame>, size 0, with method names and source file and line numbers via fields and a name resolver.

This is useful when looking at paths to and from objects via local variables as the stack frames are visible in the paths to GC roots queries.

Stack frames as pseudo-objects and running methods as pseudo-classes
Stack frames of are of type packageName.className.methodName(Signature)ReturnType extending <method> representing the method being executed, of size the stack frame size, with source file and line number via fields and a name resolver, and those methods are pseudo-classes of type <method type> of size 0.

This can be useful to find out which methods are currently running and how much stack space they take up. To examine running methods then take the histogram view, filter by '\(', then sort by instances or instance size.

Stack frames as pseudo-objects and all methods as pseudo-classes
Stack frames of are of type packageName.className.methodName(Signature)ReturnType extending <method>codeph> representing the method being executed, of size the stack frame size, with source file and line number via fields and a name resolver, and all methods are pseudo-classes of type <method type> of size based on the JITted and byte code sizes. The method sizes are then not part of the class size.

This can be useful to find out which methods have large JITted or byte code sizes. They can be viewed by going to the histogram view, then selecting <method type> and listing objects.

Memory Analyzer > DTFJ Parser > Runtime ID
Certain DTFJ dumps can contain snapshots from multiple Java Virtual Machines. This can happen with IBM z/OS system dumps. By default Memory Analyzer chooses the snapshot from JVM that caused the dump (as reported by DTFJ), or the first snapshot found. Memory Analyzer will produce a warning if additional snapshots are found. Another of these snapshots can be selected by using this option, of the form 'i.j.k' where i is the index of the address space required, j is the index of the process within that address space and k is the index of the runtime within the process. This ID is shown in a warning message when multiple dumps are found. Instead of an index, an address space identifier, process identifier or runtime identifier as shown by the warning message can be used instead. An identifier can be omitted. Example message
				Using DTFJ Java runtime 4.0.0
				Multiple Java runtimes found without a runtime ID specified in preferences. Ignoring extra Java runtime 5.0.0 found in image at address space '0x379' process ID '14568399' runtime address '0x492c6f2468' version Java(TM) SE Runtime Environment(build pmz6460sr9fp1-20110401_03 (SR9 FP1))
				Multiple Java runtimes found without a runtime ID specified in preferences. Ignoring extra Java runtime 6.0.0 found in image at address space '0x4bc' process ID '35467898' runtime address '0x492d592c98' version Java(TM) SE Runtime Environment(build pmz6460sr9fp1-20110401_03 (SR9 FP1))
				
To specify another runtime, 5.0.0 or 0x379.14568399.0x492c6f2468 or even 0x379.. or ..0x492c6f2468 could be used.
General > Appearance > Colors and Fonts > Memory Analyzer > OQL comment color
Modify the color of comments in the Object Query Language (OQL) studio.
General > Appearance > Colors and Fonts > Memory Analyzer > OQL keyword color
Modify the color of keywords in the Object Query Language (OQL) studio.