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

[Coleen Phillmore]

On 7/26/2013 10:04 AM, Daniel D. Daugherty wrote:
> 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.

Yes, this was good work to improve this test and detect this!

And yes, we should save size to compare against in debug mode (I thought 
we did in an earlier version of this code).

Coleen

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