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 <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
