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