Community
Participate
Working Groups
The DTFJ implementations for IBM Java and IBM Semeru Runtimes are different and usually incompatible, particularly for core dumps. MAT ships with a built-in update site for IBM Java DTFJ at https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/runtimes/tools/dtfj/ As of this writing, that update site was last updated in 2020 and is not actively maintained. IBM also publishes standalone update sites and packaged MAT builds for both IBM Java DTFJ and IBM Semeru Runtimes DTFJ at https://www.ibm.com/support/pages/eclipse-memory-analyzer-tool-dtfj-and-ibm-extensions However, as of this writing, those update sites are not signed. In addition, I have not found time to restart the work to add an option to MAT to specify the DTFJ implementation or pass through to the underlying JVM: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567819 So that is the current and unfortunate state of things. With that noted, as IBM Semeru Runtimes usage picks up, it is becoming a more common issue that users running with MAT + IBM Java DTFJ are trying to load dumps produced by IBM Semeru Runtimes. This produces confusing fatal errors such as the following: java.lang.NoClassDefFoundError: com.ibm.j9ddr.vm29.pointer.generated.GC_ArrayObjectModelPointer at com.ibm.j9ddr.vm29.j9.gc.GCArrayObjectModel.from(GCArrayObjectModel.java:52) at com.ibm.j9ddr.vm29.j9.gc.GCObjectModel.<init>(GCObjectModel.java:43) at com.ibm.j9ddr.vm29.j9.gc.GCObjectModel_V1.<init>(GCObjectModel_V1.java:80) at com.ibm.j9ddr.vm29.j9.gc.GCObjectModel.from(GCObjectModel.java:59) at com.ibm.j9ddr.vm29.j9.ObjectModel.<clinit>(ObjectModel.java:56) at com.ibm.j9ddr.vm29.j9.gc.GCObjectHeapIteratorAddressOrderedList_V1.advanceScanPointer(GCObjectHeapIteratorAddressOrderedList_V1.java:200) at com.ibm.j9ddr.vm29.j9.gc.GCObjectHeapIteratorAddressOrderedList_V1.next(GCObjectHeapIteratorAddressOrderedList_V1.java:283) at com.ibm.j9ddr.vm29.j9.walkers.HeapWalker.walk(HeapWalker.java:118) at com.ibm.j9ddr.vm29.view.dtfj.java.j9.HeapObjectIterator.hasNext(HeapObjectIterator.java:50) at com.ibm.j9ddr.vm29.view.dtfj.java.DTFJJavaHeap$1.hasNext(DTFJJavaHeap.java:118) at org.eclipse.mat.dtfj.DTFJIndexBuilder.fill(DTFJIndexBuilder.java:1236) [...] MAT should have some detection of this and provide a better error.
https://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=a192f1be11e2b005001eca1cea26b7150b6cf2bb https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/205821
Minor warning from the build: Should org.eclipse.mat.dtfj.DTFJIndexBuilder$DumpReliabilityResult be a _static_ inner class? This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made static. Probably doesn't matter much.
Good catch. Made the change and verified locally and all tests pass. https://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=42b50511976f6072f4f66c7a7a42e39c14ad7d7e https://git.eclipse.org/r/c/mat/org.eclipse.mat/+/205880
This issue has been migrated to https://github.com/eclipse-mat/org.eclipse.mat/issues/43.
