JNI - question about jmethodid values.

[Thomas Stüfe]

Hi Peter,

On Mon, Nov 26, 2018 at 1:02 PM Peter Hull <peterhull90 at gmail.com> wrote:
>
> Hi Thomas,
> Thank you very much for the detailed explanation. For your
> information, the relevant NetBeans bug is
> https://issues.apache.org/jira/browse/NETBEANS-1428
>
> On Sat, Nov 24, 2018 at 3:41 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> > A jmethodid is a pointer to malloc'ed memory.
> OK. Just in case I haven't understood it - does this mean a jmethodid,
> once 'created', won't change (after garbage collection or whatever)?

yes. It lives on, unchanged, forever. Even if the associated class is
unloaded. That must be since outside JNI/JVMTI code may call in with
outdated jmethodids which we must be able to handle gracefully.

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