JNI - question about jmethodid values.

[coleen.phillimore at oracle.com]

On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>> Hi Coleen,
>>
>> (moved to svc-dev since David did shoo us off discuss before :-)
>>
>> Just to be sure I understand:
>>
>>> If the class is unloaded, the jmethodID is cleared.  Native code should
>>> first test whether it's NULL.  I think that is the predictable behavior
>>> that the spec requires.
>> Wait, really? So, As a JNI caller I should do this:
>>
>> jmethodID method;
>> ..
>> if (*method == NULL) { .. invalid method id .. }  ?
>>
>> I thought jmethodid is opaque, and its value itself cannot be changed
>> from the VM, no?
>>
> Oh you probably meant "native code in the VM", not "native JNI code".
> Sorry for the confusion.

I did mean native JNI code, but I actually don't know how native JNI 
code is supposed to deal with nulled out jmethodIDs.

Maybe they predictably crash?

Coleen
>
>>> Also, the jmethodIDs were never in the PermGen but in CHeap allocated
>>> memory blocks.  The Method* that was in the jmethodID was in the
>>> permgen.  I don't think there was any guarantee of contiguity (is that a
>>> word) but they are allocated together in a block.  After permgen was
>>> removed, the blocks were sorted by class loader, so that the class
>>> loader data could point to them for clearing.
>>>
>> Ah, thank you for for clarifying. I guess I was reading your change
>> for "6964458: Reimplement class meta-data storage to use native
>> memory" wrong.
>>
>> I took a second closer look at now jmethodIDs were generated before
>> 6964458. I think see now how it worked: they were weak global
>> references living in a malloced JNIHandleBlock, similar to today, and
>> were set to NULL once the Method* is unloaded, but never removed since
>> NULL is != deleted_handle().
>>
>> Thanks, Thomas
>>
>>> Thanks,
>>> Coleen
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Jc
>>>>>
>>>>>>>> But it is not guaranteed to work. I would probably rather use a
>>>>>>>> hashmap or similar.
>>>>>>> I need to look at the implications on more detail but think it would
>>>>>>> make sense to use long/jlong instead of int/jint on all platforms; the
>>>>>>> extra memory use shouldn't be a problem. I think the IDs are just
>>>>>>> stored on the Java side and used to get the method name and signature
>>>>>>> later. That should be a loss-free cast, shouldn't it?
>>>>>> Sure.
>>>>>>
>>>>>>>> If this is
>>>>>>>> true, this 4x30bit assumption may actually have worked before jdk8,
>>>>>>>> since the java heap is allocated as one continuous space, with the
>>>>>>>> PermGen clustered in one part of it.
>>>>>>> Indeed we did only start to get crashes on JDK9 and later (only
>>>>>>> observed on Windows, macOS seems OK and other platforms have not been
>>>>>>> tested)
>>>>>>>
>>>>>>> Yours sincerely,
>>>>>>> Peter
>>>>>> Cheers, Thomas
>>>>>
>>>>> --
>>>>>
>>>>> Thanks,
>>>>> Jc