RFR: 8267752: KVHashtable doesn't deallocate entries

Ioi Lam iklam at openjdk.java.net
Wed Jun 16 04:27:36 UTC 2021


On Wed, 16 Jun 2021 03:08:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/hashtable.hpp line 268:
>> 
>>> 266:       for (KVHashtableEntry** p = bucket_addr(index); *p != NULL; ) {
>>> 267:         probe = *p;
>>> 268:         *p = probe->next();
>> 
>> Should we also call the destructor (something like `probe->_value.~V()` , not sure about the syntax). I.e., similar to `GrowableArray<E>`:
>> 
>> https://github.com/openjdk/jdk/blob/e0f6f70d3f9e748d2bc53f371beca487e9343d4a/src/hotspot/share/utilities/growableArray.hpp#L499-L501
>> 
>> This way, we can get rid of this code, and move `delete ref()` into `SourceObjInfo::~SourceObjInfo()`
>> 
>> https://github.com/openjdk/jdk/blob/e0f6f70d3f9e748d2bc53f371beca487e9343d4a/src/hotspot/share/cds/archiveBuilder.hpp#L180-L186
>
> I wanted to do that (and even had a version that did), but unfortunately for this code, adding a destructor to SrcObjRef destroys the ref pointer in this scope, so we'd need to have a copy constructor etc to keep the pointer alive.
> 
> https://github.com/openjdk/jdk/blob/e0f6f70d3f9e748d2bc53f371beca487e9343d4a/src/hotspot/share/cds/archiveBuilder.cpp#L464
> 
> So I thought we should wait until we replace this table to make it better.  I was going to add a comment here.

Sounds good. The current code is a bit clumsy but there's no memory leak anymore. We should eventually move all functionalities of KVHashTable into ResourceHashtable so we don't have 2 different partially working hashtable types!

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

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


More information about the hotspot-dev mailing list