Skip to main content

jmap -histo

6 replies [Last post]
veerendra_c
Offline
Joined: 2006-05-19
Points: 0

Is "jmap -histo" supposed to trigger a garbage collection? If it does not trigger a garbage collection, if you are trying to figure out what objects are causing a memory leak, it will be hard to do that as the object counts that show up in the histogram will depend on how long it has been since the last tenured GC. Any ideas on how this could be overcome?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
alexlamsl
Offline
Joined: 2004-09-02
Points: 0

Even if there isn't a full garbage collection, I think the swap-scan for dead objects are carried out rather frequently. So I'd assume that these dead objects won't be showing up in your histogram, hence detection of memory leaks shouldn't be a problem.

veerendra_c
Offline
Joined: 2006-05-19
Points: 0

That does not seem to be the case at least with jdk 1.5.0_06. I see that there is a memory grom the GC log as the heap size after a tenured GC is increasing with time.
So, I tried doing a jmap -histo at various hourly intervals, and sometimes the total size of the objects in the histogram s say after 2 hours of the test is far larger than the histogram after 9 hours, even though per the GC log, tenured memory usage was increasing with time. I heard that with the Beta 6 version of JDK (Mustang), jmap -histo will trigger a full GC. I will try it and see what happens.

veerendra_c
Offline
Joined: 2006-05-19
Points: 0

I tried using Mustang java version, and jmap -histo still did not trigger a full GC, per the GC log. Please correct me if I am wrong but I am thinking this is happening probably because option DisbaleExplicitGC is being being used when starting the application.

briand
Offline
Joined: 2005-07-11
Points: 0

In JDK 5.0, jmap -histo works using native debugger apis and finds the heap via symbolic information in the target process. However, it has no clue about the state of the heap at the time it collects the histogram. The JVM might be running application threads or it may be in the middle of a GC operation. jmap can't tell the difference between live and dead objects as it is not be able to trace all roots. So the histogram it generates is certainly fuzzy at best.

In Mustang, jmap uses the attach on demand mechanism and communicates directly to logic embedded in the JVM. When trying to get a histogram, it brings the JVM to a safepoint, performs a full gc and then collects the histogram data. It's much more accurate (though potentially more intrusive due to the full gc event, particularly on apps with large heaps). The -XX:+DisableExplicitGC flag should not prevent the jmap - histo induced full gc event and you should see a Full GC message from -verbosegc.

Message was edited by: briand

veerendra_c
Offline
Joined: 2006-05-19
Points: 0

The jmap -histo did not trigger a full gc per the GC logs with 1.6.0-beta-b59g JVM version.

I got the 1.6.0-beta-b84 version and it is indeed triggering a full GC. That's great news. Thanks.

Message was edited by: veerendra_c

alanb
Offline
Joined: 2005-08-08
Points: 0

This has recently changed in the mustang workspace. By default ( jmap -histo
) it will *not* trigger a full GC and it will print a histogram of all objects in the heap. If you use the "live" suboption ( jmap -histo:live
) then it will trigger a full GC and the output will be that of a histogram of the live/reachable objects only. I believe these changes should be available in mustang b89.