RFR: 8309603: Deallocate hashtables in ClassLoaderData::unload [v3]

[Coleen Phillimore]

On Thu, 13 Jul 2023 00:03:14 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8309603](https://bugs.openjdk.org/browse/JDK-8309603)
>> 
>> Memory is released in `ClassLoaderdata::~ClassLoaderData` for the dictionary and module hashtables but they could be deleted earlier in `ClassLoaderdata::unload`. Since we're unloading the class loader is no longer being used for lookup.
>> 
>> Additional testing:
>> - [x] Linux x86_64 fastdebug `tier2`
>> - [x] Linux x86_64 release `tier2`
>> - [x] Linux x86_64 fastdebug `gtest:all`
>> - [x] Linux x86_64 release `gtest:all`
>> - [x] Linux x86_64 fastdebug `test/hotspot/jtreg/runtime`
>> - [x] Linux x86_64 release `test/hotspot/jtreg/runtime`
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move package deallocation back to deconstructor

Unload cannot just call the destructor because it's not safe to release the metaspace chunk yet, until the next handshake operation.  Since ZGenerational may take a while to request a handshake, this might be able to release some memory beforehand.  @fisk asked for this.
Did releasing the package table not work?

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

PR Comment: https://git.openjdk.org/jdk/pull/14820#issuecomment-1636324767