heap dump

[Hiroshi Yamauchi]

Hi Swamy,

On Wed, Jan 14, 2009 at 3:53 PM, Swamy Venkataramanappa <
swamyv at central.sun.com> wrote:

> One of our GC expert says:
>
>> These could be deadwood left behind in the heap because
>> a compacting collection did not do a complete compaction
>> of the heap (but left behind a "dense" prefix uncompacted
>> and therefore with holes which were converted to look like
>> in arrays). Those would appear as int arrays. Are these only
>> int arrays or something else? Also, with the help of jhat
>> if you can find the addresses of these objects are they
>> kind of towards the early (lower address) part of the
>> old generation? The deadwood is left behind because
>> it may be too expensive to compact out that deadwood
>> for very little gain (in terms of space freed).
>
>
They are all (primitive) int arrays with fairly random sizes (on the
magnitude of 10K or 100K). I'm not sure if they are at lower address though
(I only have the heap dump output at this point.)

But it sounds like that's what's happening. I assume those int arrays are
not real objects and when GC works harder they will vanish. Correct?

Thanks,
Hiroshi



>
>>
>>
> I hope this helps.
>
> Thanks,
> Swamy
>
>
>
> Hiroshi Yamauchi wrote:
>
>> Hi,
>>
>> I take a heap dump using the dumpHeap method described in
>>
>>
>> http://java.sun.com/javase/6/docs/jre/api/management/extension/com/sun/management/HotSpotDiagnosticMXBean.html
>>
>> with the live parameter true and I see objects (int arrays) which have
>> nothing in the "References to this object" section in the jhat output.
>> This is on an openjdk6 b11 build.
>>
>> What could it mean?
>>
>> Thanks,
>> Hiroshi
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20090114/a750a4ff/attachment.html