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

[Daniel D. Daugherty]

On 7/26/13 5:50 AM, Coleen Phillmore wrote:
>
> On 7/26/2013 6:12 AM, frederic parain wrote:
>>>     If the allocate/deallocate subsystem doesn't support partial
>>> deallocates
>>>      then why does deallocate() have a size parameter? If you always
>>> have to
>>>      deallocate() exactly what you allocate()'ed, then deallocate() 
>>> only
>>> needs
>>>      the pointer originally returned by allocate() and doesn't need the
>>> size
>>>      parameter.
>>
>> I'm not familiar enough with Metaspace to answer this questions. I'll
>> let the NPG experts respond to this one.
>
> We pass the size because the block that is allocated does  not have 
> the size stored in it (to save 1 word of space per allocation).   So 
> you can't just free the pointer.

Isn't there some sanity check info in the non-product version?
Can the allocate() size be saved there and verified at deallocate()
time in non-product mode? I wouldn't be surprised if such a check
revealed other smaller leaks.

The {Redefine,Retransform}BigClass tests are rather abusive in their
hunt for a specific style of memory leak and we were lucky that they
caught this leak also. We're also fortunate that Ivan G. improved
the tests to catch smaller memory leaks.

Dan


>
> Coleen
>
>>
>> Thanks,
>>
>> Fred 
>