|Uses of the Memory Analyzer for Eclipse Development [message #1928]
||Mon, 04 February 2008 17:14
| Andreas Buchen
Registered: July 2009
we proposed to contribute the Memory Analyzer a couple of weeks ago. Let
me give you a better picture of what it is and how it could be of use to
The Memory Analyzer works with HPROF heap dumps. A heap dump is a complete
picture of all objects held in memory at a given point of time. One can
browse the objects, see why they are not garbage collected (path to GC
roots), what memory they keep alive (retained set) and how big that chunk
is (retained size).
Okay, that's business as usual, you say. Well, the Memory Analyzer allows
you to extend it by something called queries. This is what you can do:
* Group objects by class loader: Any up-to-date architecture loads
components with separate class loaders, be it osgi or JEE application
servers. The Memory Analyzer allows you to extract meaningful names for
different types of class loaders. Thereby one directly sees the object X
was loaded by plug-in Y.
* Identify leaking class loaders: Ever seen memory consumption go up after
each deploy-undeploy-deploy cycle? This can happen if the component does
not de-register itself properly. But how do you find out? Using the Memory
Analyzer, one could easily build a query that displays the classes (or
class loaders) which should not be there anymore. Of course, to do this,
you need the implementation know-how which of the class loaders are valid
applications. For example, we know our application server keeps a
reference to valid class loaders in some registry. So all class loaders
not contained therein are suspicious. We extract those suspects for
further analysis. This type of query is also applicable to Eclipse
Plug-ins and/or other open source servers.
Other highlights that come to my mind: The Memory Analyzer works on
multi-GB production heap dumps. Actually, that is the reason why we
started developing the tool in the first place. We couldn't find other
tools that enabled us to look into a 50 million object heap dump.
And one more thing: the retained size of any object is directly available.
And the retained sizes of arbitrary object sets can be approximated very
quickly. This is important as the retained size is the most important
indicator when looking for memory leaks.
Powered by FUDForum
. Page generated in 0.01794 seconds