简体   繁体   中英

How can a jmap live heap dump contain unreachable objects?

I used jmap to dump the live heap of an application using CMS GC:

jmap -dump:live,format=b,file=heap.hprof <pid>

I opened this dump with YourKit and it found that 61% of the 8Gb heap was unreachable, specifically

Objects unreachable from GC roots, but not yet collected 126963949 5149290840 5149290840

I thought that using -dump:live meant that it would only contain reachable objects?

The gc.log file for the application is suspiciously absent of any full GC caused by my invocation of jmap, and instead shows these lines either side of my taking the dump:

2019-07-17T09:32:59.808+0200: 33177.365: [GC (GCLocker Initiated GC) 2019-07-17T09:32:59.808+0200: 33177.365: [ParNew: 233127K->230550K(3397376K), 0.0265604 secs] 8029404K->8026859K(18496896K), 0.0267558 secs] [Times: user=0.92 sys=0.03, real=0.03 secs] 
2019-07-17T09:34:43.807+0200: 33281.363: [CMS-concurrent-preclean: 3.165/105.760 secs] [Times: user=143.74 sys=12.71, real=105.76 secs] 

In the first ParNew collection after the first CMS reset after the heap dump was taken, I see that the heap is roughly the size that was live in the heap dump (around 3-4Gb):

2019-07-17T09:34:55.850+0200: 33293.407: [GC (GCLocker Initiated GC) 2019-07-17T09:34:55.850+0200: 33293.407: [ParNew: 3264332K->260834K(3397376K), 0.0435628 secs] 6814726K->3811241K(18496896K), 0.0438372 secs] [Times: user=1.45 sys=0.04, real=0.05 secs] 

So maybe in this case jmap did not trigger a full GC? Is that possible/configurable?

It does seem unexpected.

You can try using jcmd <pid> GC.heap_dump filename=MyHeapdump

It is the new recommended way to do a heap dump, and will force a Full GC by default. See oracle doc :

GC.heap_dump [options] [arguments]

Generates a HPROF format dump of the Java heap.

Impact: High — depends on the Java heap size and content. Request a full GC unless the -all option is specified.

There is this bug report from 2015 which states that the young generation is not being collected with -dump:live. I suppose this behaviour has not been changed.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM