On Mon, 25 Oct 2021 21:33:33 GMT, David Holmes <dhol...@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
