On 11/28/18 10:08 AM, Thomas Stüfe wrote:
On Wed, Nov 28, 2018 at 4:03 PM <coleen.phillim...@oracle.com> wrote:
On 11/28/18 10:00 AM, Thomas Stüfe wrote:
On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe <thomas.stu...@gmail.com> wrote:
Hi Coleen,
(moved to svc-dev since David did shoo us off discuss before :-)
Just to be sure I understand:
If the class is unloaded, the jmethodID is cleared. Native code should
first test whether it's NULL. I think that is the predictable behavior
that the spec requires.
Wait, really? So, As a JNI caller I should do this:
jmethodID method;
..
if (*method == NULL) { .. invalid method id .. } ?
I thought jmethodid is opaque, and its value itself cannot be changed
from the VM, no?
Oh you probably meant "native code in the VM", not "native JNI code".
Sorry for the confusion.
I did mean native JNI code, but I actually don't know how native JNI
code is supposed to deal with nulled out jmethodIDs.
Maybe they predictably crash?
Coleen
I always thought it would gracefully reject, e.g. on JVMTI with
JVMTI_ERROR_INVALID_METHODID.
Save that JC wrote that there are some JNI function sequences where
the VM would still crashes:
<quote jc>
- Get a jmethodID and remember it
- Wait until the class gets unloaded
- Get the class to get reloaded and try call the old jmethodID
(which now points to NULL), the code will segfault
</quote>
which looks like just a bug to me.
It may be misuse of JNI also. We don't guarantee a lot of things with
JNI. Maybe instead of clearing, we could install a Method* that throws
NSME.
But I guess why leak the jmethodID memory if it's going to crash anyway
when using it?
Coleen
..Thomas
