[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    JMap/JHat hex values
From:       kelly.ohair () oracle ! com (Kelly O'Hair)
Date:       2012-06-24 16:43:20
Message-ID: 68779828-B645-4AB8-813B-B5142221A6AA () oracle ! com
[Download RAW message or body]


On Jun 23, 2012, at 3:20 AM, Alan Bateman wrote:

> On 22/06/2012 21:10, Max Grossman wrote:
> > Hi all,
> > 
> > I'm curious if anyone can tell me about the hex values displayed on a \
> > jhat-generated page from a heap dump using jmap? I get a heap dump using: 
> > jmap -heap:format=b pid
> > 
> > and then process it using jhat:
> > 
> > 
> One thing to know is that there are many ways to generate a HPROF heap dump:
> 
> 1. With the built-in heap dump support, meaning "jmap -dump:file=<file> <pid>" or \
> -XX:+HeapDumpOnOutOfMemoryError. 
> 2. With the serviceability agent on core files or hung processes, "jmap -F \
> -dump:file=<file> <pid>" or the undocumented jmap -heap:format=b option that you \
> are using. Note that there is no guarantee that you will get a consistent heap dump \
> when you use this approach, mostly because data structures and the heap may be in \
> an inconsistent state. 

Correct. Be careful on this one.

> 3. With the HPROF agent when you specify the heap option.

At least with HPROF, there was a goal to try and treat these as unique object ID's \
and not physical addresses. So they would also carry over from dump to dump so you do \
heap dump comparisons between two sample times. Since all the data in the dumps from \
HPROF came from the HPROF data, it could come closer to being in a guaranteed state, \
where it all gets locked down before the dump happens. The physical address of \
objects can change, and the actual HPROF IDs do not change.

But of course, of these 3 options, HPROF will be the slowest, and use the most \
memory, but may provide some information that options 1 and 2 do not, stack traces on \
object allocations was one as I recall.

> 
> For 1 & 2 then the the object ID of instances in the heap dump is the object \
> address so you can make some inferences. For 3 then it's an ID assigned by the \
> HPROF agent so will not be useful to what I suspect you are doing.

I'd warn anyone from making too many inferences, I suspect the patterns you get could \
be drastically different with each garbage collector. :^(

-kto

> 
> -Alan.


[prev in list] [next in list] [prev in thread] [next in thread]