Not sure if this discussion is diverging but to be clear there is no way
for a JNI programmer to check whether a jmethodid is valid or not. The
onus is one the programmer to ensure classes are not unloaded while
there are pre-computed jmethodid's. It's a quality of implementation
issue, to me,
On 11/28/18 11:46 AM, JC Beyler wrote:
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:
"RETURNS:
Returns the result of calling the static Java method.
THROWS:
Exceptions raised during the
What I meant was that since we already pay for the memory leak, we
could just change this behavior and handle NULL methodIDs gracefully.
We do this already for JVMTI.
Otherwise, if we do not what to do this check and consider this to be
the caller's responsibility, I do not see the point of
On Wed, Nov 28, 2018 at 4:19 PM wrote:
>
>
>
> On 11/28/18 10:08 AM, Thomas Stüfe wrote:
> > On Wed, Nov 28, 2018 at 4:03 PM wrote:
> >>
> >>
> >> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> >>> On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe
> >>> wrote:
> Hi Coleen,
>
> (moved to
On 11/28/18 10:08 AM, Thomas Stüfe wrote:
On Wed, Nov 28, 2018 at 4:03 PM wrote:
On 11/28/18 10:00 AM, Thomas Stüfe wrote:
On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe wrote:
Hi Coleen,
(moved to svc-dev since David did shoo us off discuss before :-)
Just to be sure I understand:
On Wed, Nov 28, 2018 at 4:03 PM wrote:
>
>
>
> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> > On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe
> > wrote:
> >> Hi Coleen,
> >>
> >> (moved to svc-dev since David did shoo us off discuss before :-)
> >>
> >> Just to be sure I understand:
> >>
> >>> If
On 11/28/18 10:00 AM, Thomas Stüfe wrote:
On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe 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
On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe 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
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?
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 wrote:
> A jmethodid is a pointer to malloc'ed memory.
OK. Just in case I haven't
Hi JC,
On Mon, Nov 26, 2018 at 10:39 PM JC Beyler wrote:
>
> Hi Thomas,
>
> Not sure I agree either (but this first part of the email might be you and I
> rat-holing and we could/should perhaps just let it go :-)):
> - The specs do not say at all what happens to the internals of the
>
Hi Dean,
On Mon, Nov 26, 2018 at 10:44 PM 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,
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,
Hi Thomas,
Not sure I agree either (but this first part of the email might be you and
I rat-holing and we could/should perhaps just let it go :-)):
- The specs do not say at all what happens to the internals of the
jmethodIDs and not even that de-referencing them is safe. You are right
that the
Please all, don't cc the discuss list once a topic has been directed to
the correct mailing list!
Thanks,
David
On 27/11/2018 5:33 am, Thomas Stüfe wrote:
Hey JC,
On Mon, Nov 26, 2018 at 8:15 PM JC Beyler wrote:
Hi all,
Just added my two cents on one comment:
On Mon, Nov 26, 2018 at
Hey JC,
On Mon, Nov 26, 2018 at 8:15 PM JC Beyler wrote:
>
> Hi all,
>
> Just added my two cents on one comment:
>
> On Mon, Nov 26, 2018 at 5:00 AM Thomas Stüfe wrote:
>>
>> Hi Peter,
>>
>> On Mon, Nov 26, 2018 at 1:02 PM Peter Hull wrote:
>> >
>> > Hi Thomas,
>> > Thank you very much for the
Hi Peter,
On Mon, Nov 26, 2018 at 1:02 PM Peter Hull 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 wrote:
> > A
Hi Peter,
(adding serviceability)
A jmethodid is a pointer to malloc'ed memory.
In more detail, jmethodid points to a table slot containing pointers
to Method* objects, and that table itself lives in C heap. See class
JNIMethodBlock, JNIMethodBlockNode:
18 matches
Mail list logo
