RFR: 8268406: Deallocate jmethodID native memory [v2]

[Serguei Spitsyn]

On Tue, 17 Jun 2025 13:56:41 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> If we remove a jmethodID, we need to keep the number for it in case some JVMTI code still thinks that number is valid.  So we can't decrement the entry count.
>
> 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.

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

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