JNI - question about jmethodid values.

[JC Beyler]

Hi all,

Just added my two cents on one comment:

On Mon, Nov 26, 2018 at 5:00 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> 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.
>
>
This is the current design and most likely will remain for quite a bit but
it is not defined by the SPEC to be like this so, in essence, it is an
implementation detail that could be not true in future releases ;-)

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