Re: [rvm-research] Why more heap required to finish Dacapo iteration runs?

Hi Andreas,

Thank you for the explanation first!
This becomes interesting, since I tested it with Hotspot 1.7 and Jikes 3.1.3. Dump the heap and compare what is changing is a good way.

One question is will the compiled code after warmups be in the heap dumps? Or we can just compare real heap usage between two GCs (like, GC size_x -> size_y, and so size_x is the real heap usage for nursery)?
 
Thanks!
Best
Junjie


On Sunday, August 10, 2014 3:58 AM, Andreas Sewe <[email protected]> wrote:
 


Hi,


> This problem is not in Jikes only, but also in Hotspot too.
> More heap is required if run Dacapo benchmark more iteration numbers,
> and this is different for different benchmarks. For example,
> lusearch/xalan/avorora require an significant increase but others do not.
> 
> Could some one give me some explanation, or link on this?

of the top of my head, there could be several explanations:

- Over time, the amount of JIT compiled code grows. At least on the
meta-circular Jikes RVM, compiled code is part of the same heap
(although kept in a different space therein) as application objects. I
don't think this is the case in HotSpot, though, where compiled code is
not kept in the heap controlled by -Xmx.

- Over time, class metadata accumulates. This can happen if the
benchmark generates classes (e.g., instances of Proxy) on the fly but
either some instances or their ClassLoader are not garbage collected.
Like compiled code, Jikes RVM also keeps class metadata in the same
heap. Older releases of HotSpot used a different heap (called permgen
space) for this kind of data, but AFAIK newer versions don't.

- There is some kind of "leak", e.g., a map holding onto objects from a
previous iteration that grows over time. To diagnose this, I would
recommend comparing two heap dumps taken after different numbers of
iteration to see of which classes the additional instances are (e.g.,
Map.Entry).

Hope this helps.

Andreas


------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers