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

[Erik Österlund]

On Tue, 25 Jul 2023 00:46:08 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:
> 
>   Unload packages in unload

The design for concurrent class unloading was to essentially do this:
1. Unlink unloading data
2. Handshake all threads potentially accessing unloading data
3. Delete unloading data
The reason for this order, is that it provides safe memory reclamation. We want to do this consistently, so we don't get races where the code works 99.999999% of the time, except when you get a nasty race that crashes the JVM.
So unfortunately, this patch goes in the wrong direction, I think. I don't think we should do this.

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

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