RFR: 8268406: Deallocate jmethodID native memory [v2]

[Coleen Phillimore]

On Tue, 17 Jun 2025 23:28:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> That is not was I was trying to propose. What I tried to describe was this:
>> 
>> ```c++
>> // The value of the next jmethodID. This only increments (always unique IDs)
>> static uint64_t _jmethodID_counter = 0; 
>> // Tracks the number of jmethodID entries in the _jmethod_id_table. 
>> // Incremented on insert, decremented on remove. Use to track if we need to resize the table.
>> static uint64_t _jmethodID_entry_count = 0;
>> 
>> 
>> The problem with using `_jmethodID_counter` as a proxy for how many entries there are in the table is that it will diverge over time as we keep calling remove due to class unloading.
>> 
>> Using a separate variable lets us resize based on what is actual in the table.
>
> Interesting suggestion to consider. I'm not sure yet if it is really important.

This makes sense because we want to know how many items are in the table vs. how many items have been in the table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154424321