RFR: 8268406: Deallocate jmethodID native memory [v2]

[Axel Boldt-Christmas]

On Tue, 17 Jun 2025 12:27:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/jmethodIDTable.cpp line 126:
>> 
>>> 124: static bool needs_resize(Thread* current) {
>>> 125:   return ((_jmethodID_counter > (_resize_load_trigger * table_size(current))) &&
>>> 126:          !_jmethod_id_table->is_max_size_reached());
>> 
>> Should we not just have a separate jmethodID entry count variable we use here instead, that is incremented and decremented on insert and remove. Rather than using the next jmethodID counter which just grows monotonically regardless of any removals.
>
> 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.

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

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