Tools which look into heap dumps just mix together everything they find in memory. They group all objects by class in a class histogram or display the objects in flat lists. That’s it, but that’s far from sufficient. When I inspect a heap dump I am interested to isolate my share in the memory or what the memory distribution of all deployed services/applications on the server is.
The SAP Memory Analyzer shows memory distribution per deployment unit, i.e. per deployed service or application. It takes the class loader as a hint and by knowing which classes where loaded by which class loader it can tell to which deployment unit an object belongs – on a SAP JVM you get a meaningful name for those class loaders. Try it out. Go to the class histogram and group by class loader! Or even better, go to the dominator tree and use class loader grouping there!
Class loaders work so well because whenever you partition major components or allow for re-loadable components you use them. That’s true for application servers, but it’s also true for platforms like Eclipse. Class loaders are your boundary and when you like to account some memory to the deployment unit which keeps it alive, the class loader is the way to do it.
The views in the SAP Memory Analyzer allow for grouping by class or class loader, including even the console. With this it’s much easier to determine what memory belongs to which deployed component. And it’s easier to tell what the footprint of all of them is.