JNIMethodBlockNode leak question

[coleen.phillimore at oracle.com]

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