To generate a heap dump, you typically use the jmap utility, for example:
> jmap -dump:live,format=b,file=mydump.hprof <JVM pid>
Note the “live” flag above: it forces the JVM to perform a Full GC before generating the dump. If this flag is omitted, no GC is performed and the resulting dump may contain (a lot of) garbage. Which kind of a dump is preferable?
Oftentimes, garbage objects are less important than the live ones. Modern GCs are optimized for efficient collection of temporary object that become garbage quickly. And a handful of very long-lived objects that eventually became unreachable, may probably stay as garbage for long time with no negative effect. Thus, if you have a memory leak, or your application live set is too big, i.e. your important objects are live, it doesn’t make sense to analyze a “full” heap dump. The garbage objects will just create noise and obscure the objects that you really care about.
However, if your app experiences long GC pauses, especially those due to Old or Mixed collections, analyzing a heap dump with garbage may make a lot of sense. Long GC pauses are often the result of collecting objects that are neither short-lived nor long-lived, that become unreachable after getting promoted into the Old Gen of the heap. When that’s the case, heap dump analysis may help you to identify such objects. For example, if your app is essentially a mid-tier cache, you may discover that a big part of garbage is objects that were once contained in this cache but then got evicted. Such objects are typically the worst from the GC standpoint, and thus reducing their size, modifying your eviction policy or increasing the cache may be the best way to improve GC performance.
One way to determine whether or not your heap dump has some “bad” garbage as explained above, is to open the “Where memory goes, by GC Root” section of the JXRay report and expand the “Unreachable” subsection. If there are mostly separate String, char[] and other “free-floating” garbage objects there, they are most likely temporary, short-lived and thus good. On the other hand, if you see many big subtrees of objects that represent your business logic, it’s a bad sign – the GC may have difficulty collecting such objects.
To summarize: analyze only live heap dumps unless you want to speed up garbage collection, and in the latter case, watch for garbage objects that form big groups (subtrees).