Hi Dean, On Mon, Nov 26, 2018 at 10:44 PM <dean.l...@oracle.com> wrote: > > Doesn't the spec say it's the caller's responsibility to keep the class from > being unloaded? > > " > A field or method ID does not prevent the VM from unloading the class from > which the ID has been derived. After the class is unloaded, the method or > field ID becomes invalid. The native code, therefore, must make sure to: > > keep a live reference to the underlying class, or > recompute the method or field ID > > if it intends to use a method or field ID for an extended period of time. > > The JNI does not impose any restrictions on how field and method IDs are > implemented internally. > > " > > > however, then the JVMTI spec has errors like JVMTI_ERROR_INVALID_METHODID > that seem to imply that the JVM can (or must?) detect an invalid methodid. > > dl >
Yes, I took the fact that JVMTI functions can return JVMTI_ERROR_INVALID_METHODID to be a requirement that the VM must be able to detect this, and therefore the jmethodid slot must not move or be reused. Thanks, Thomas > On 11/26/18 11:33 AM, Thomas Stüfe wrote: > > Hey JC, > > On Mon, Nov 26, 2018 at 8:15 PM JC Beyler <jcbey...@google.com> wrote: > > Hi all, > > Just added my two cents on one comment: > > On Mon, Nov 26, 2018 at 5:00 AM Thomas Stüfe <thomas.stu...@gmail.com> wrote: > > 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. > > 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 ;-) > > I politely disagree :) > > JNI spec says that you have a function like this: > > jmethodID GetMethodID(..) > > returning a jmethodid which you can then use in subsequent JNI > functions. These functions are required to behave in a predictable way > if the jmethodid has gotten invalid. The spec has no way to inform the > caller if a jmethodid has gotten invalid by class unloading. Since the > jmethodid is handed up to the caller and stored by him, there is no > way to change its value on the fly either. > > So even though the spec does not specifically say that jmethodid lives > forever, it is laid out in a way that prevents jmethodids from ever > becoming invalid, and from changing their numerical value. This can of > course change, but not without changing the JNI spec. > > I think my point is that Peter can rely on this behavior without fear > that it will change in the future without him noticing. Before this > behavior changes, the JNI spec would have to change. > > Cheers, Thomas > > > > > > > > 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 > >
