RFR: 8268406: Deallocate jmethodID native memory
Coleen Phillimore
coleenp at openjdk.org
Fri Jun 13 20:39:33 UTC 2025
On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection. JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward. JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr. With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr. Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated. When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table. This mechanism increases the method_idnum to do this. In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code. But that's not in this change.
>
> Tested with tier1-4, 5-7.
There is a way to create a jmethodID from an obsolete method and I thought we had tests that did this. I'm not finding them right now. The old and obsolete methods can still be running after a redefinition if they were running during the redefinition. The JIT deoptimizes them but they will be run in the interpreter. New invocations of the method will choose the new version of the method always. Always unless there's a bug that we don't know about. We have fixed a few old method invocations in the past coming from various places in the JVM but we fixed the "last" one fairly recently.
But technically, one could create a jmethodID to an obsolete method although it's not easy to do. I was musing above but not committed to breaking compatibility if there is code that requires this.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2971620203
More information about the hotspot-dev
mailing list