RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock
Coleen Phillimore
coleenp at openjdk.java.net
Mon Oct 25 22:20:17 UTC 2021
On Mon, 25 Oct 2021 22:16:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> 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.
Is the suggestion to have a default parameter to free CHEAP structures that's false for deallocate_contents?
-------------
PR: https://git.openjdk.java.net/jdk/pull/6105
More information about the serviceability-dev
mailing list