[jdk20] RFR: 8298084: Memory leak in Method::build_profiling_method_data [v3]
Coleen Phillimore
coleenp at openjdk.org
Tue Dec 13 02:26:24 UTC 2022
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
More information about the hotspot-dev
mailing list