JMap/JHat hex values

[Andrew Haley]

On 06/22/2012 09:10 PM, Max Grossman wrote:

> 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:
>
> jhat heap.bin
>
> and on some of the class pages generated by jhat, you'll get
> listings like:
>
> References to this object:
>
> LongObj at 0x7d5e4d7f0 (80 bytes) : ??
> LongObj at 0x7d5e4d7a0 (80 bytes) : ??
> LongObj at 0x7d5e4d840 (80 bytes) : ??
> LongObj at 0x7d5e4d610 (80 bytes) : ??
> LongObj at 0x7d5e4d700 (80 bytes) : ??
> LongObj at 0x7d5e4d750 (80 bytes) : ??
> LongObj at 0x7d5e4d890 (80 bytes) : ??
> LongObj at 0x7d5e4d5c0 (80 bytes) : ??
> [Ljava.lang.Object;@0x7d5e403d8 (96 bytes) : Element 1 of [Ljava.lang.Object;@0x7d5e403d8
> LongObj at 0x7d5e4d6b0 (80 bytes) : ??
> LongObj at 0x7d5e4d660 (80 bytes) : ??
>
> where each of those lines represents a different object in the
> heap. Are those hex values virtual addresses of the actual object
> (or possibly related to virtual addresses?). It seems like there
> must be some mapping as those are 10 objects allocated in close
> temporal proximity in the application, and those hex values are each
> separated by 80 bytes (the object size), but I'm curious if I can
> rely on that in any way or if this is just a lucky coincidence for
> this one micro-application (code attached) I made purely for testing
> this behavior.

Allocation on the heap is pretty simple: you just decrement a pointer.
So, you'd expect a bunch of objects allocated at the same time to be
together.  There are some complications to do with thread-local
allocation, and of course if there's more than one thread all bets are
off.  Later on, objects that are still alive may be moved out of the
Eden space.

What are you trying to do?  Is this just curiosity, or ... ?

Andrew.