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.stu...@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)? > > 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? > > 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
