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
-Xmx4g
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 are the parsing of the dump and building
of the dominator tree. Try parsing the heap
dump from the command line, perhaps on a bigger machine. The dumps
and index files can then be copied to a more convenient machine.
Once the dump has been parsed, it usually can
be opened with less memory in the GUI.
As a rough estimate if the number of objects is N and the number of
classes C, it might take at least T bytes to parse and build the dominator tree
where:
T ≈ N * 28.25 + C * 1000 + P
P is the space used by the DTFJ or HPROF parsers. For a PHD file, the space could be:
P ≈ C * 1000
Memory Analyzer uses additional memory for caching index files, so
performance will be better if there is more memory available than the minimum
required to parse a dump.
Memory Analyzer has an architectural limit of 231 - 3 objects, a current limit of 231 - 9 = 2,147,483,639 objects, but has not been tested with that many objects. The current record is a heap dump file of 159Gbytes containing 2,041,300,061 objects, which was opened with Memory Analyzer running with a 172Gbyte heap. Exceeding the limit can result in an exception such as java.lang.OutOfMemoryError: Requested length of new long[2,147,483,640] exceeds limit of 2,147,483,639. See enable discard for options to work around this limit.
The preference page is opened via a menu option.
There is a option (from MAT 1.5 onwards) to display bytes in B, KB, MB, GB, or Smart formats. The default is to always display in Bytes format to match the previous MAT behavior and not cause any confusion. The option can be changed in the Eclipse preference dialog or using -Dbytes_display=(bytes|kilobytes|megabytes|gigabytes|smart).
Sometimes a heap dump is generated with more objects than Memory Analyzer can handle, either from lack of heap to run Memory Analyzer itself, or because the number exceeds the Memory Analyzer limit of 2,147,483,639 objects. This option controls some experimental settings to help analyze such huge dumps, by purposely discarding objects in the original heap dump.
The discarded objects are counted in the unreachable objects histogram together with any unreachable objects discarded by Memory Analyzer after parsing but before building the dominator tree.
The discarded objects are not indexed, so are not part of the dominator tree nor are they counted as part of the retained size. As they are not indexed they will not appear in the list objects query. Most other queries will not operate on unindexed (discarded) objects. Sometimes it is possible to view them. The inspector view can display unindexed objects in the attributes and statics tabs. It is possible to 'Go Into' an unindexed object from the inspector view, and 'Go Back' to the previous object. Unindexed objects do not have GC root information, so in that position in the inspector view is displayed a warning triangle and the message Unindexed. Names resolvers can use the values of unindexed objects to find a displayable name for an object. This will be displayed after the object address in the inspector view and in the Inspector View value tab.
<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.
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.
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.
This is a change in behavior from previous releases when a warning was shown in the error log and processing continued. This default change was made to alert the user to a potential problem either with the file itself or a bug in the JVM or in MAT. You may choose to change the strictness of the parser:
<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.
packageName.className.methodName(Signature)ReturnType
extending <method>
representing the method being executed,
of size an estimate of 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.
The size of a stack frame is estimated as 8 bytes times the maximum number of object references from a frame of that type.
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.