RFR: 8252049: Native memory leak in ciMethodData ctor [v2]

[Coleen Phillimore]

On Fri, 4 Dec 2020 12:45:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance.
>> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap.
>> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs.
>> 
>> Proposed fix is to run Mutex destructor right away. 
>> 
>> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach.
>> 
>> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive.
>> 
>> Testing:
>> - [x] verified that no memory leak observed with the reported test
>> - [x] tier1-4
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Introduce MethodData::MDHeader class
>  - Merge branch 'master' into 8252049.md.leak
>  - Cleanup
>  - Merge branch 'master' into 8252049.md.leak
>  - Minor refactoring
>  - Fix native memory leak in ciMethodData ctor

This looks like a nice refactoring to me.

src/hotspot/share/oops/methodData.hpp line 1972:

> 1970:   }; // Public flag values
> 1971: 
> 1972:   class MDHeader : public StackObj {

MDHeader appears to be a Value Obj and not a StackObj, so it shouldn't inherit from StackObj.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1478