Hi Peter, (adding serviceability)
A jmethodid is a pointer to malloc'ed memory. In more detail, jmethodid points to a table slot containing pointers to Method* objects, and that table itself lives in C heap. See class JNIMethodBlock, JNIMethodBlockNode: http://hg.openjdk.java.net/jdk/jdk/file/30a02b4e6c06/src/hotspot/share/oops/method.cpp#l1928 If I understand the NetBeans profiler coding right, they assume the jmethodIDs to cluster in up to four clusters of relative vicinity, with each cluster spanning 30 bits? That is quite an assumption to make. This may work more or less accidentally, since malloc'ed pointers are also clustered naturally. A Clib implementation may allocate only in the traditional data segment (below sbrk) - I believe AIX and Solaris do this - which means all malloced pointers are as close to each other as the data segment is large. But C-Libraries often allocate C-Heap memory in separate mmape'd blocks (e.g. glibc arenas), and there is no guarantee where those blocks are. You may still often get lucky - if all jmethod id block allocations happen in a short timeframe, or if you just have not many users of C-Heap in the process. But it is not guaranteed to work. I would probably rather use a hashmap or similar. Side note: I believe (and someone please correct me if I am wrong) that jmethodid used to live in the PermGen, in the Java Heap, and that only since the PermGen removal in JDK8 they live in C-Heap. 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. Best Regards, Thomas On Sat, Nov 24, 2018 at 3:51 PM Peter Hull <peterhul...@gmail.com> wrote: > > 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
