Question about jmethodId and class unloading

[Thomas Stüfe]

Thank you, Volker.

I was actually concerned about AsyncGetCallTrace, which seems to return
just an array of jmethodIds as stack. These could become invalid the moment
they are handed out.

Cheers, Thomas

On Wed, Apr 13, 2022 at 2:51 PM Volker Simonis <volker.simonis at gmail.com>
wrote:

> 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
>>
>