Hi Peter, On Mon, Nov 26, 2018 at 1:02 PM Peter Hull <peterhul...@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.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)?
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
