RFR: JDK-8298084: Memory leak in Method::build_profiling_method_data

[Justin King]

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