JNIMethodBlockNode leak question

[Thomas Stüfe]

Hi Coleen,

thank you, and thanks for the archaeology (so I was wrong about the
pre-permgen-removal history).

I agree that normally this should not be an issue, and the case I had
was a weird outlier.

Thanks, Thomas
On Wed, Nov 28, 2018 at 12:47 AM <coleen.phillimore at oracle.com> wrote:
>
>
> Hi Thomas,
>
> Yes, you read this right.  These are leaked.  I believe the spec tells
> us to, but I can't find it right now.  We also implemented it this way
> with PermGen elimination so that it would be compatible with how it was
> before that.  My measurements were for some applications (not jvmti) was
> that there were few jmethodIDs.
>
> Sorry for the delayed answer.
> Coleen
>
> On 11/8/18 2:33 AM, Thomas Stüfe wrote:
> > 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
>