<div dir="ltr"><div dir="ltr">Sorry I meant:<div><a href="https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp17074">https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp17074</a><br></div><div><br></div><div>:)</div><div>Jc</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 9:02 AM <<a href="mailto:coleen.phillimore@oracle.com">coleen.phillimore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="m_-5421616575364801678moz-cite-prefix">On 11/28/18 11:46 AM, JC Beyler wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">The biggest issue is that the JNI spec has no
means of "gracefully" exiting when a jmethodID is NULL, take
the call static methods, the spec says:
<div><br>
</div>
<div>"RETURNS:<br>
</div>
<div>
<div>Returns the result of calling the static Java method.</div>
<div><br>
</div>
<div>THROWS:</div>
<div>Exceptions raised during the execution of the Java
method."</div>
</div>
<div><br>
</div>
<div>So now, this has to get fixed to say something like it
might throw if the jmethodID is not valid? Seems "messy"
to me, I'd rather just fix the spec where it says:</div>
<div><br>
</div>
<div>
<div>PARAMETERS:</div>
<div>env: the JNI interface pointer.</div>
<div>clazz: a Java class object.<br>
</div>
<div>methodID: a static method ID.<br>
</div>
<div><br>
</div>
</div>
<div>to saying:</div>
<div>
<div>PARAMETERS:</div>
<div>env: the JNI interface pointer.</div>
<div>clazz: a Java class object.<br>
</div>
<div>methodID: a valid static method ID.<br>
</div>
<br class="m_-5421616575364801678gmail-Apple-interchange-newline">
</div>
</div>
</div>
</div>
</blockquote>
<br>
I don't think the spec should be changed so that jmethodID prevents
a class from being unloaded.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Thanks,</div>
<div>Jc</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Nov 28, 2018 at 8:36 AM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What I meant
was that since we already pay for the memory leak, we<br>
could just change this behavior and handle NULL methodIDs
gracefully.<br>
We do this already for JVMTI.<br>
<br>
Otherwise, if we do not what to do this check and consider
this to be<br>
the caller's responsibility, I do not see the point of keeping
the<br>
NULLed-out jmethodID tables around. What for, just to make the
crash<br>
to be a bit more predictable?<br>
<br>
..Thomas<br>
<br>
<br>
<br>
On Wed, Nov 28, 2018 at 5:22 PM JC Beyler <<a href="mailto:jcbeyler@google.com" target="_blank">jcbeyler@google.com</a>> wrote:<br>
><br>
> We pay for it to support easily the JVMTI spec. JNI does
not check for NULL and will crash if you pass a jmethod that
points to NULL. I've checked that pretty much every method
will crash as they all call resolve_jmethod_id at the start.<br>
><br>
> As I said before, it's not a bug, the spec is just
ambiguous because at the method definitions of the spec it
just says the jmethodIDs have to come from a GetMethodID call
but the more general spec that both I and Dean quoted say that
it is the native agent's job to ensure the class does not get
unloaded to keep the jmethod valid [1].<br>
><br>
> Thanks,<br>
> Jc<br>
><br>
> [1] <a href="https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp16696" rel="noreferrer" target="_blank">https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp16696</a><br>
</blockquote>
</div>
</blockquote>
<br>
I believe this describes the JNI function table, not jmethodIDs.<br>
<br>
No, a jmethodID doesn't keep the class from being unloaded, nor do
we want it to. This would add undue burden to the GCs, in that they
would have to trace metadata or some side structure of oops to keep
classes alive that have jmethodIDs.<br>
<br>
Coleen<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> On Wed, Nov 28, 2018 at 7:38 AM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>>
wrote:<br>
>><br>
>> On Wed, Nov 28, 2018 at 4:19 PM <<a href="mailto:coleen.phillimore@oracle.com" target="_blank">coleen.phillimore@oracle.com</a>>
wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On 11/28/18 10:08 AM, Thomas Stüfe wrote:<br>
>> > > On Wed, Nov 28, 2018 at 4:03 PM <<a href="mailto:coleen.phillimore@oracle.com" target="_blank">coleen.phillimore@oracle.com</a>>
wrote:<br>
>> > >><br>
>> > >><br>
>> > >> On 11/28/18 10:00 AM, Thomas Stüfe
wrote:<br>
>> > >>> On Wed, Nov 28, 2018 at 3:59 PM
Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>>
wrote:<br>
>> > >>>> Hi Coleen,<br>
>> > >>>><br>
>> > >>>> (moved to svc-dev since David
did shoo us off discuss before :-)<br>
>> > >>>><br>
>> > >>>> Just to be sure I understand:<br>
>> > >>>><br>
>> > >>>>> If the class is unloaded,
the jmethodID is cleared. Native code should<br>
>> > >>>>> first test whether it's
NULL. I think that is the predictable behavior<br>
>> > >>>>> that the spec requires.<br>
>> > >>>> Wait, really? So, As a JNI
caller I should do this:<br>
>> > >>>><br>
>> > >>>> jmethodID method;<br>
>> > >>>> ..<br>
>> > >>>> if (*method == NULL) { ..
invalid method id .. }Â ?<br>
>> > >>>><br>
>> > >>>> I thought jmethodid is opaque,
and its value itself cannot be changed<br>
>> > >>>> from the VM, no?<br>
>> > >>>><br>
>> > >>> Oh you probably meant "native code
in the VM", not "native JNI code".<br>
>> > >>> Sorry for the confusion.<br>
>> > >> I did mean native JNI code, but I
actually don't know how native JNI<br>
>> > >> code is supposed to deal with nulled
out jmethodIDs.<br>
>> > >><br>
>> > >> Maybe they predictably crash?<br>
>> > >><br>
>> > >> Coleen<br>
>> > > I always thought it would gracefully
reject, e.g. on JVMTI with<br>
>> > > JVMTI_ERROR_INVALID_METHODID.<br>
>> > ><br>
>> > > Save that JC wrote that there are some JNI
function sequences where<br>
>> > > the VM would still crashes:<br>
>> > ><br>
>> > > <quote jc><br>
>> > >Â Â Â - Get a jmethodID and remember it<br>
>> > >Â Â Â - Wait until the class gets unloaded<br>
>> > >Â Â Â - Get the class to get reloaded and try
call the old jmethodID<br>
>> > > (which now points to NULL), the code will
segfault<br>
>> > > </quote><br>
>> > ><br>
>> > > which looks like just a bug to me.<br>
>> ><br>
>> > It may be misuse of JNI also. We don't
guarantee a lot of things with<br>
>> > JNI. Maybe instead of clearing, we could
install a Method* that throws<br>
>> > NSME.<br>
>> ><br>
>> > But I guess why leak the jmethodID memory if
it's going to crash anyway<br>
>> > when using it?<br>
>> ><br>
>><br>
>> Precisely :) We pay for it, we may just as well use
it.<br>
>><br>
>> ..Thomas<br>
>><br>
>> > Coleen<br>
>> ><br>
>> > ><br>
>> > > ..Thomas<br>
>> ><br>
><br>
><br>
><br>
> --<br>
><br>
> Thanks,<br>
> Jc<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_-5421616575364801678gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div><br>
</div>
Thanks,
<div>Jc</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div>Thanks,<div>Jc</div></div></div>