RFR(S): JDK-8019845 NPG: Memory leak during class redefinition

Coleen Phillmore coleen.phillimore at oracle.com
Thu Jul 25 21:34:11 UTC 2013


Frederic,
This fix looks good.
Thanks!
Coleen

On 7/25/2013 11:15 AM, frederic parain wrote:
> Greetings,
>
> Please review this small fix:
>
> open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/
> bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845
>
> The bug title is "NPG: Memory leak during class redefinition" but
> the leak is in the metaspace code.
>
> To store metadata, the VM allocates memory chunks using
> SpaceManager::allocate(). In this method, a "raw_word_size"
> is computed from the MetaspaceObject size and some
> alignment constraints to determine the size of the memory
> chunk needed. A look up is performed in the free list to
> find a chunk of this size, if none is found, a new chunk
> is allocated.
>
> When a memory chunk is not used anymore, for instance when
> a class is redefined and the old metadata are discarded, it
> is returned to the free list.
>
> The problem is that the memory chunk is returned to the free
> list using its MetaspaceObject size without considering alignment
> constraints. If the "raw_word_size" computed in
> SpaceManager::allocate() is different from the MetaspaceObject
> size, look ups in the free list cannot find returned chunks
> because of the size difference, causing the leak.
>
> The fix is to return memory chunks using the same size
> computation as the one used in SpaceManager::allocate().
>
> Tested with:
>   RedefineBigClass.sh output (checking the memory leak
>   doesn't show up anymore)
>   JPRT
>   vm.quick.testlist
>   vm.runtime.testlist
>   vm.parallel_class_loading.testlist
>
> Thanks,
>
> Fred
>




More information about the hotspot-gc-dev mailing list