JMap/JHat hex values
Kelly O'Hair
kelly.ohair at oracle.com
Sun Jun 24 09:43:20 PDT 2012
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.
More information about the serviceability-dev
mailing list