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@0x7d5e4d7f0 (80 bytes) : ?? > LongObj@0x7d5e4d7a0 (80 bytes) : ?? > LongObj@0x7d5e4d840 (80 bytes) : ?? > LongObj@0x7d5e4d610 (80 bytes) : ?? > LongObj@0x7d5e4d700 (80 bytes) : ?? > LongObj@0x7d5e4d750 (80 bytes) : ?? > LongObj@0x7d5e4d890 (80 bytes) : ?? > LongObj@0x7d5e4d5c0 (80 bytes) : ?? > [Ljava.lang.Object;@0x7d5e403d8 (96 bytes) : Element 1 of > [Ljava.lang.Object;@0x7d5e403d8 > LongObj@0x7d5e4d6b0 (80 bytes) : ?? > LongObj@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.
