[jdk20] RFR: 8298084: Memory leak in Method::build_profiling_method_data [v3]

[Coleen Phillimore]

On Tue, 13 Dec 2022 01:16:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This boolean prevents us from calling the MethodData destructor twice and releasing MethodData C heap memory twice.  InstanceKlass::deallocate_contents calls release_C_heap_structures with it false, and then calls through the Metadata pointer hierarchy to MetadataFactory::free_metadata, which calls the MethodData destructor and MethodData::deallocate_contents which calls MethodData::release_C_heap_structures().   This is the delegation scheme for releasing metadata between InstanceKlass and ConstantPool.
>> 
>> InstanceKlass::release_C_heap_structures() is also called during class unloading and must walk the whole metadata, releasing C heap memory.  It's passed true. It doesn't go through deallocate_contents because the metadata is freed together at the same time with the metaspace that contains it.
>
> Thanks Coleen I see now how the code has been shuffled around:
> 
> Old code:
> 
> InstanceKlass::deallocate_contents
> -> release_C_heap_structures(/* release_sub_metadata */ false);
>   -> methods_do(method_release_C_heap_structures);
>     -> m->release_C_heap_structures
>       -> method_data()->~MethodData();
> -> deallocate_methods(loader_data, methods());
>   -> MetadataFactory::free_metadata(loader_data, method);
> 
> New code:
> 
> InstanceKlass::deallocate_contents
> -> release_C_heap_structures(/* release_sub_metadata */ false);
> -> deallocate_methods(loader_data, methods());
>   -> MetadataFactory::free_metadata(loader_data, method);
>     -> method_data()->~MethodData();

Yes, plus releasing the JVMCI thing that MethodData points to also.

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

PR: https://git.openjdk.org/jdk20/pull/13