On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe <thomas.stu...@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.
> >
> > 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
> >
