RFR: 8268406: Deallocate jmethodID native memory [v10]

[David Holmes]

On Tue, 24 Jun 2025 14:46:12 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> > the `cls` parameter is never actually used. So while it is supposed to refer to the class you have the static method jMethodID for, there is no requirement that it actually does, and could even be null.
> 
> Not passing in the cls parameter, would be a clear user error though, right? And one that would have crashed before, because if you racingly execute bytecodes of a class that is being unloaded, things would blow up one way or another. To me it seems like the user should just pass in the class as intended and then all is good.

The point is to try and make things more robust when the user does the unexpected. As Coleen stated we are trying to handle cases where JNI code looks up a jMethodID in one place, stashes it away and then uses it elsewhere with no guarantee the class is being kept alive. I agree you would think they would have, and pass in, the original jclass reference, but the fact we don't actually use that value is not hard to determine and JNI code can take advantage of that - treating the `jMethodId` as an effective raw pointer to a method.

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3002494069