JNIMethodBlockNode leak question

[Thomas Stüfe]

No-one?
On Wed, Nov 7, 2018 at 11:38 AM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi all,
>
> I wonder whether I understand this correctly:
>
> When a caller requests a jmethodId bei either calling
> jni-GetMethodId() or jvmti-GetClassMethods(), the returned jmethodId
> is a pointer into a slot of a table containing the respective Method*
> pointers. That table is tied to the ClassLoaderData. When the
> classloader is unloaded and its ClassLoaderData deleted, we do not
> delete that table, but rather deliberately leak it after zeroing it
> out. The reason - if I understand the comment in ~ClassLoaderData
> correctly - is that jmethodId live forever - a caller may hand it in
> long after the class has been unloaded, and this should be handled
> gracefully.
>
> We cannot simply delete its JNIMethodBlockNode, since the jmethodId
> then would either point to unmapped memory - which we could handle
> with SafeFetch - but worse could point to memory reused for a
> different purpose.
>
> We also could not reuse that slot, since then that jmethodId would
> point to a different method? Apart from the fact that we would need
> infrastructure for that, a global pool of JNIMethodBlockNode, with
> associated locking etc.
>
> Have I understood this correctly or am I off somewhere?
>
> And if I am right, that would mean that were we to generate classes
> over and over again in new class loaders and accessing their methods
> with JNI, we would have a slowly growing leak, even if we clean up the
> loaders?
>
> Thanks, Thomas