JNI - question about jmethodid values.

[Peter Hull]

I have recently been looking at some native code that's part of the
NetBeans profiler. This code was crashing for me because it was based
on incorrect assumptions about the sizes of various primitive types.
There is some code which is intended to map jmethodid values to jint
values (see below). This is trivial on 32 bit platforms because the
are the same size. However on 64-bit platforms this is not the case
because jmethodid is (according to the docs) to be treated as a
pointer to an opaque structure and is 64-bit.
So, the code splits the 64-bit jmethodid into a 30-bit 'offset' part
and a 34-bit 'base' part. It then stores the high part in one of four
slots and returns a 32 bit int which is 2 bits for the slot id and 30
bits from the offset part. For the reverse process, it looks up the
slot id, gets the base address and ORs it with the offset. This seems
to work in practice but it is based on the assumption that all
jmethodids will have one of only four base parts - any more than four
can't be specified by a 2 bit id.
So my question is: is this a sound assumption? The answer needs some
detailed knowledge of the internals of the JRE I suppose, so if this
mailing list is not the right place to ask, what is the right place?
I want to fix my crash in the netbeans profiler but I want to do the
right thing rather than just patching it up (which I have done by
doing casts more carefully)
Thanks for your help.
Peter

For reference, the code is on github:
https://github.com/apache/incubator-netbeans/blob/5405b8c93eeafdd213cffcc59df002464af8d838/profiler/lib.profiler/native/src-jdk15/Stacks.c#L66-L92
and: https://github.com/apache/incubator-netbeans/blob/5405b8c93eeafdd213cffcc59df002464af8d838/profiler/lib.profiler/native/src-jdk15/Stacks.c#L66-L92