On Tue, 17 Jun 2025 12:27:02 GMT, Coleen Phillimore <[email protected]> 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
