JNI - question about jmethodid values.

[Thomas Stüfe]

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?

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