RFR: 8268406: Deallocate jmethodID native memory [v2]

[Daniel D. Daugherty]

On Mon, 16 Jun 2025 15:34:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderData.cpp line 594:
>> 
>>> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them
>>> 593: // after the associated classes and class loader are unloaded, subsequent lookups
>>> 594: // for these ids will return null since they are no longer found in the table.
>> 
>> Perhaps: s/null/nullptr/
>
> I thought the convention was that we were supposed to call it `null` in the comments and `nullptr` in the code.

I'm not sure, but your reasoning sounds good to me!

>> src/hotspot/share/oops/method.cpp line 2063:
>> 
>>> 2061: 
>>> 2062: // jmethodID handling
>>> 2063: // jmethodIDs are 64-bit integers that will never run out and are mapped in a table
>> 
>> Should we have a `guarantee` or `assert` somewhere that the counter never wraps?
>
> Okay, I added one when we increment the jmethod_id_counter.
> 
>   // Update jmethodID global counter.
>   _jmethodID_counter++;
>   guarantee(_jmethodID_counter != 0, "must never go back to zero");
> 
> I think this will detect wraparound.

Thanks!

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

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