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
Also, the jmethodIDs were never in the PermGen but in CHeap allocated
memory blocks. The Method* that was in the jmethodID was in the
permgen. I don't think there was any guarantee of contiguity (is that a
word) but they are allocated together in a block. After permgen was
removed, the blocks were sorted by class loader, so that the class
loader data could point to them for clearing.
Ah, thank you for for clarifying. I guess I was reading your change
for "6964458: Reimplement class meta-data storage to use native
memory" wrong.
I took a second closer look at now jmethodIDs were generated before
6964458. I think see now how it worked: they were weak global
references living in a malloced JNIHandleBlock, similar to today, and
were set to NULL once the Method* is unloaded, but never removed since
NULL is != deleted_handle().
Thanks, Thomas
Thanks,
Coleen
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
