Question about jmethodId and class unloading

[Volker Simonis]

For an instance method you need an instance of that class anyway if you
want to call the method, so the class can't be unloaded.

But in general you're right, JNI gives you no guarantees at all. It even
explicitly warns about this situation. See:
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#accessing_fields_and_methods

Thomas Stüfe <thomas.stuefe at gmail.com> schrieb am Mi., 13. Apr. 2022, 12:22:

> Hi,
>
> In hotspot, jmethodId is an address to a slot in a table-like structure of
> Method*. We ensure that the slot never goes away, so the slot address is
> always valid. But we reuse the slot - if a class is unloaded, its method
> ids are released by marking their slot with a canary. Later it could get
> reused for a different Method*.
>
> I must miss something really obvious, but what prevents an outside caller
> from using an invalid or outdated method id via JNI?
>
> If the method id got released, on CallXXXMethod, we stop the VM with a
> fatal JNI error (if CheckJNICalls=1). But there is no way to gracefully
> continue, right?
>
> And what happens if the slot got reused by the VM, so it now contains a
> different Method* ? There is no way catch that, right?
>
> Do both cases just boil down to "the JNI programmer should know when class
> unloading did happen, and should not use the jmethodid beyond that point"?
>
> Thanks a lot,
>
> Thomas
>