Native Memory Leak

[coleen.phillimore at oracle.com]

On 2/7/18 2:27 PM, Jacob Schlather wrote:
> I hope this is the right mailing list. I've been tracking down a memory
> leak that seems to be related to
> https://bugs.java.com/view_bug.do?bug_id=8162795. Running on Java 1.8.0_144
> with native memory tracking enabled, we've been seeing the internal memory
> size grow until the kernel kills the JVM for using too much memory. Using
> the native memory detail diff tool I've been able to find the following
> items that seem to be growing, one being a MemberNameTable
>
> [0x00007efffa8d29fd] GenericGrowableArray::raw_allocate(int)+0x17d
> [0x00007efffab86456] MemberNameTable::add_member_name(_jobject*)+0x66
> [0x00007efffa8ffb24] InstanceKlass::add_member_name(Handle)+0x84
> [0x00007efffab8777d] MethodHandles::init_method_MemberName(Handle,
> CallInfo&)+0x28d
>                               (malloc=106502KB +106081KB #19)
>
>   and another being some JNI allocations

The MemberNameTable in jdk8 used jweak as pointers to MemberNames so the 
below increases in JNI block memory would also be accountable to the 
MemberNameTable.   We fixed this temporarily in jdk8 and 9 to leak less 
memory but it still leaked.  The long term non-leaking fix is in jdk10, 
which is pointed to by the bugs you found.

I would follow Andrew Haley's suggestion and see if you can find and 
reduce the use of MethodHandles in the application.   I don't think we 
have any workarounds other than backporting the jdk10 fix, or adding a 
diagnostic option to disable the table.   If you don't use 
RedefineClasses, this table is unnecessary.

Were these the highest differences in the native memory that were 
observed using NMT?

Thanks,
Coleen


>
> [0x00007efffa9ce58a] JNIHandleBlock::allocate_block(Thread*)+0xaa
> [0x00007efffad36830] JavaThread::run()+0xb0
> [0x00007efffabe7338] java_start(Thread*)+0x108
>                               (malloc=23903KB +23697KB #78452 +77776)
>
> [0x00007efffa9ce58a] JNIHandleBlock::allocate_block(Thread*)+0xaa
> [0x00007efffa94f7fb] JavaCallWrapper::JavaCallWrapper(methodHandle, Handle,
> JavaValue*, Thread*)+0x6b
> [0x00007efffa9506c4] JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x884
> [0x00007efffa904001] InstanceKlass::register_finalizer(instanceOopDesc*,
> Thread*)+0xf1
>                               (malloc=19770KB +19727KB #64887 +64745)
>
> [0x00007efffa9ce58a] JNIHandleBlock::allocate_block(Thread*)+0xaa
> [0x00007efffa94f7fb] JavaCallWrapper::JavaCallWrapper(methodHandle, Handle,
> JavaValue*, Thread*)+0x6b
> [0x00007efffa9506c4] JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*)+0x884
> [0x00007efffa9513a1] JavaCalls::call_virtual(JavaValue*, KlassHandle,
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x321
>                               (malloc=29794KB +29563KB #97786 +97028)
>
> Having found these I could use some guidance on what to look at next and
> what sorts of calls could potentially be causing these issues. We don't
> have any explicit uses of JNI that I can tell in our code bases. Let me
> know if there's anymore information that would be helpful.