Question about jmethodId and class unloading

Volker Simonis volker.simonis at gmail.com
Wed Apr 13 16:06:50 UTC 2022


But that's a known problem, isn't it?

And if I remember right you took great care in the SAP JVM Profiler to
handle similar situations :)

On Wed, Apr 13, 2022 at 4:25 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> 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


More information about the hotspot-runtime-dev mailing list