RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock

[Coleen Phillimore]

On Mon, 25 Oct 2021 21:33:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The Mutex destructor isn't called for the MDO lock.  We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn.  It was easily reproduced with that patch.  It is not easily reproduced otherwise.
>> I tested this change with that patch though and it passes tier1-6,
>
> src/hotspot/share/oops/instanceKlass.cpp line 2692:
> 
>> 2690: 
>> 2691: // Called also by InstanceKlass::deallocate_contents
>> 2692: void InstanceKlass::release_C_heap_structures_internal() {
> 
> Why do we have two different cleanup functions here? It seems overly subtle that `deallocate_contents` only calls `release_C_heap_structures_internal`, rather than `release_C_heap_structures`. And now the only difference is whether `constants()->release_C_heap_structures()` is called, it seems to me that distinction should perhaps be more explicit in the caller.

// Can't release the constant pool here because the constant pool can be
     // deallocated separately from the InstanceKlass for default methods and
     // redefine classes.

Because of this comment.  We have two ways that we can get to ConstantPool::deallocate_contents.  We don't have two ways to get to the Method::deallocate_contents.

The deallocate list contains unloaded/unattached Methods (from the relocator for jsr/ret), scratch classes from redefinition, fully formed constant pools from default methods, or fully formed InstanceKlass from classfile parsing errors or class definition errors.

Only the constant pool case should be separated out in deallocate_contents, which is why it's excluded.

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

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