RFR: JDK-8298084: Memory leak in Method::build_profiling_method_data
Justin King
jcking at openjdk.org
Tue Dec 6 07:11:34 UTC 2022
On Tue, 6 Dec 2022 07:01:16 GMT, David Holmes <dholmes at openjdk.org> wrote:
> I'm somewhat confused by the existing code. We have:
>
> ```
> // Destroy MethodData
> method_data()->~MethodData();
> ```
>
> which doesn't actually delete the `MethodData` it just runs the destructor. So where is the `MethodData` object actually allocated, and when is that freed? I would expect the lock to disappear at the same time if it is embedded in the `MethodData` object.
Mutex used to be a value member (this change switches it to be a pointer), so ~MethodData actually deleted the lock and its associated data. However calling the destructor like that, and then accessing fields later is really sketchy and I am pretty sure undefined behavior to some extent.
Many of the other Metadata derived classes use `deallocate_contents()` to release other metadata objects and `release_C_heap_structures()` to cleanup non-metadata memory. So I was just attempting to be consistent.
https://github.com/openjdk/jdk/commit/86fdbc0f85de6494cd7f6a5ad12d745ea382df93 addressed the original leak and called the destructor directly, but a more recent change re-introduced another leak.
-------------
PR: https://git.openjdk.org/jdk/pull/11526
More information about the hotspot-dev
mailing list