Community
Participate
Working Groups
OS:Window 7 professional JDK:jdk1.7.0_21 64bit mat Ver :MemoryAnalyzer-1.3.1.20140107-win32.win32.x86_64 MemoryAnalyzer.int [ -startup plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502 -vm C:\Program Files\Java\jdk1.7.0_21\bin\java -vmargs -Xmx4g ] I open a dump with 1.5G size and to open leak suspect report but the following error occurred. [ An internal error occurred during: "default_report org.eclipse.mat.api:suspects". Java heap space ]
And MY PC's RAM is 8G Byte
What is the exact stack trace of the error from Window > Error Log. What kind of dump is it (HPROF?, PHD?). The dump should have been parsed, so can you close the dump, then reopen it without running any report? Does the error recur if you then run the leak suspects report?
(In reply to Andrew Johnson from comment #2) > What is the exact stack trace of the error from Window > Error Log. I will upload it on April 28 > What kind of dump is it (HPROF?, PHD?). It is HPROF > The dump should have been parsed, so can you close the dump, then reopen it > without running any report? Yes other report can open without any problem. > Does the error recur if you then run the leak suspects report? YES ,run the leak suspects report and the dialog error window shows [ An internal error occurred during: "default_report org.eclipse.mat.api:suspects". Java heap space ]
Opening a 1829MB IBM core file (Objects: 6,222,655 Heap size: 568,182,763) with Memory Analyzer with -Xmx300m and running the leak suspects report gave me the following error. eclipse.buildId=unknown java.version=1.8.0_05 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86_64 Error Mon May 12 12:49:24 BST 2014 An internal error occurred during: "default_report org.eclipse.mat.api:suspects". java.lang.OutOfMemoryError: Java heap space at org.eclipse.mat.parser.internal.snapshot.MultiplePathsFromGCRootsComputerImpl.bfs(MultiplePathsFromGCRootsComputerImpl.java:174) at org.eclipse.mat.parser.internal.snapshot.MultiplePathsFromGCRootsComputerImpl.computePaths(MultiplePathsFromGCRootsComputerImpl.java:82) at org.eclipse.mat.parser.internal.snapshot.MultiplePathsFromGCRootsComputerImpl.getPathsByGCRoot(MultiplePathsFromGCRootsComputerImpl.java:107) at org.eclipse.mat.inspections.LeakHunterQuery.findCommonPathForSuspects(LeakHunterQuery.java:864) at org.eclipse.mat.inspections.LeakHunterQuery.execute(LeakHunterQuery.java:160) at org.eclipse.mat.query.registry.ArgumentSet.execute(ArgumentSet.java:132) at org.eclipse.mat.query.registry.CommandLine.execute(CommandLine.java:93) at org.eclipse.mat.report.internal.QueryPart.execute(QueryPart.java:96) at org.eclipse.mat.report.internal.SectionPart.execute(SectionPart.java:61) at org.eclipse.mat.report.TestSuite.execute(TestSuite.java:129) at org.eclipse.mat.report.internal.RunRegisterdReport.execute(RunRegisterdReport.java:50) at org.eclipse.mat.query.registry.ArgumentSet.execute(ArgumentSet.java:132) at org.eclipse.mat.ui.QueryExecution$ExecutionJob.run(QueryExecution.java:180) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
I ran a leak suspects report on a dump generated by MAT itself in comment 4, and also looked at the memory occupied by Strings. Perhaps Field names should be commoned as Fields retain 82MB. Class Name | Objects | Shallow Heap | Retained Heap ------------------------------------------------------------------------------------------------- java.lang.String | 895,992 | 21,503,808 | 77,016,440 |- org.eclipse.mat.snapshot.model.Field | 673,874 | 16,172,976 | 82,813,408 |- org.eclipse.mat.parser.model.ClassImpl | 39,560 | 4,114,240 | 99,361,096 |- java.util.HashMap$Node | 65,135 | 2,084,320 | 12,597,488 | |- java.util.HashMap$Node[] | 8,114 | 664,496 | 13,087,752 | | |- java.util.HashMap | 8,111 | 389,328 | 13,123,016 | | |- org.eclipse.emf.ecore.impl.EPackageRegistryImpl| 2 | 96 | 1,216 | | |- java.lang.ProcessEnvironment | 1 | 48 | 2,288 | | '- Total: 3 entries | | | | |- java.util.HashMap$Node | 12,772 | 408,704 | 4,562,736 | '- Total: 2 entries | | | |- org.eclipse.mat.snapshot.model.FieldDescriptor | 79,389 | 1,905,336 | 7,157,904 -------------------------------------------------------------------------------------------------
Another way a lot of memory could be used is in the Paths2GCroots query. From the same dump above I found the following. There 910,811 path entries held in 862.336 FIFO entries. Only a few of those paths are used in the HTML report. Class Name | Shallow Heap | Retained Heap ----------------------------------------------------------------------------------------------------------------------------------------- org.eclipse.mat.internal.snapshot.inspections.Path2GCRootsQuery$Tree @ 0xf702e058 | 32 | 44,130,232 |- <class> class org.eclipse.mat.internal.snapshot.inspections.Path2GCRootsQuery$Tree @ 0xf702dfe0 | 0 | 0 |- snapshot org.eclipse.mat.parser.internal.SnapshotImpl @ 0xf2e0e618 | 64 | 114,966,536 |- computer org.eclipse.mat.parser.internal.SnapshotImpl$PathsFromGCRootsComputerImpl @ 0xf6eb2030 | 80 | 44,113,160 | |- <class> class org.eclipse.mat.parser.internal.SnapshotImpl$PathsFromGCRootsComputerImpl @ 0xf6f6ff38| 0 | 0 | |- this$0 org.eclipse.mat.parser.internal.SnapshotImpl @ 0xf2e0e618 | 64 | 114,966,536 | |- inboundIndex org.eclipse.mat.parser.index.IndexReader$InboundReader @ 0xf2ea3dc0 | 32 | 10,240 | |- excludeMap java.util.HashMap @ 0xf6eb1bc0 | 48 | 1,440 | |- fifo java.util.LinkedList @ 0xf6eb2080 | 32 | 42,555,560 | |- visited org.eclipse.mat.collect.BitField @ 0xf6eb20a0 | 16 | 777,864 | |- excludeInstances org.eclipse.mat.collect.BitField @ 0xf6eb20b0 | 16 | 777,864 -----------------------------------------------------------------------------------------------------------------------------------------
This issue has been migrated to https://github.com/eclipse-mat/org.eclipse.mat/issues/21.
