11

On Android, a direct ByteBuffer does not ever seem to release its memory, not even when calling System.gc().

Example: doing

Log.v("?", Long.toString(Debug.getNativeHeapAllocatedSize()));
ByteBuffer buffer = allocateDirect(LARGE_NUMBER);
buffer=null;
System.gc();
Log.v("?", Long.toString(Debug.getNativeHeapAllocatedSize()));

gives two numbers in the log, the second one being at least LARGE_NUMBER larger than the first.

How do I get rid of this leak?


Added:

Following the suggestion by Gregory to handle alloc/free on the C++ side, I then defined

JNIEXPORT jobject JNICALL Java_com_foo_bar_allocNative(JNIEnv* env, jlong size)
    {
    void* buffer = malloc(size);
    jobject directBuffer = env->NewDirectByteBuffer(buffer, size);
    jobject globalRef = env->NewGlobalRef(directBuffer);
    return globalRef;
    }

JNIEXPORT void JNICALL Java_com_foo_bar_freeNative(JNIEnv* env, jobject globalRef)
    {
    void *buffer = env->GetDirectBufferAddress(globalRef);
    free(buffer);
    env->DeleteGlobalRef(globalRef);
    }

I then get my ByteBuffer on the JAVA side with

ByteBuffer myBuf = allocNative(LARGE_NUMBER);

and free it with

freeNative(myBuf);

Unfortunately, while it does allocate fine, it a) still keeps the memory allocated according to Debug.getNativeHeapAllocatedSize() and b) leads to an error

W/dalvikvm(26733): JNI: DeleteGlobalRef(0x462b05a0) failed to find entry (valid=1)

I am now thoroughly confused, I thought I at least understood the C++ side of things... Why is free() not returning the memory? And what am I doing wrong with the DeleteGlobalRef()?

Kasper Peeters
  • 1,502
  • 2
  • 17
  • 35
  • 1
    allocateDirect allocates memory that is guaranteed not to be garbage collected. – Jon Willis Feb 20 '11 at 21:59
  • That's fine, but can I free it by hand somehow? Seems silly to have functionality to allocate memory but not be able to do the inverse. I'm happy with freeing it from JNI if that is an option. – Kasper Peeters Feb 20 '11 at 22:12
  • 4
    Jon > `allocateDirect` allocates memory that is guaranteed not to be **relocated** by the garbage collector. But as soon as the `ByteBuffer` gets collected, the native memory is reclaimed. – Gregory Pakosz Feb 20 '11 at 23:03
  • see my edited answer about `NewGlobalRef` and `DeleteGlobalRef` – Gregory Pakosz Feb 21 '11 at 20:31
  • possible duplicate of [When does System.gc() do anything](http://stackoverflow.com/questions/66540/when-does-system-gc-do-anything) – Raedwald Dec 24 '14 at 14:46

4 Answers4

23

There is no leak.

ByteBuffer.allocateDirect() allocates memory from the native heap / free store (think malloc()) which is in turn wrapped in to a ByteBuffer instance.

When the ByteBuffer instance gets garbage collected, the native memory is reclaimed (otherwise you would leak native memory).

You're calling System.gc() in hope the native memory is reclaimed immediately. However, calling System.gc() is only a request which explains why your second log statement doesn't tell you memory has been released: it's because it hasn't yet!

In your situation, there is apparently enough free memory in the Java heap and the garbage collector decides to do nothing: as a consequence, unreachable ByteBuffer instances are not collected yet, their finalizer is not run and native memory is not released.

Also, keep in mind this bug in the JVM (not sure how it applies to Dalvik though) where heavy allocation of direct buffers leads to unrecoverable OutOfMemoryError.


You commented about doing controlling things from JNI. This is actually possible, you could implement the following:

  1. publish a native ByteBuffer allocateNative(long size) entry point that:

    • calls void* buffer = malloc(size) to allocate native memory
    • wraps the newly allocated array into a ByteBuffer instance with a call to (*env)->NewDirectByteBuffer(env, buffer, size);
    • converts the ByteBuffer local reference to a global one with (*env)->NewGlobalRef(env, directBuffer);
  2. publish a native void disposeNative(ByteBuffer buffer) entry point that:

    • calls free() on the direct buffer address returned by *(env)->GetDirectBufferAddress(env, directBuffer);
    • deletes the global ref with (*env)->DeleteGlobalRef(env, directBuffer);

Once you call disposeNative on the buffer, you're not supposed to use the reference anymore, so it could be very error prone. Reconsider whether you really need such explicit control over the allocation pattern.


Forget what I said about global references. Actually global references are a way to store a reference in native code (like in a global variable) so that a further call to JNI methods can use that reference. So you would have for instance:

  • from Java, call native method foo() which creates a global reference out of a local reference (obtained by creating an object from native side) and stores it in a native global variable (as a jobject)
  • once back, from Java again, call native method bar() which gets the jobject stored by foo() and further processes it
  • finally, still from Java, a last call to native baz() deletes the global reference

Sorry for the confusion.

Gregory Pakosz
  • 65,227
  • 16
  • 134
  • 162
  • That is extremely helpful, thanks! Yes, I am having the problem related to the VM bug. I prefer to have explicit control, as the alternative is to allocate a buffer with an estimated size, and that estimate is almost always far larger than what I actually need. – Kasper Peeters Feb 21 '11 at 13:54
  • I must be missing something about the form of disposeNative you suggested. Would you mind having a look at the added comment? Thanks a lot. – Kasper Peeters Feb 21 '11 at 20:14
  • hmm, i didn't try it myself indeed. remove calls to NewGlobalRef and DeleteGlobalRef – Gregory Pakosz Feb 21 '11 at 20:20
  • [@Gregory Pakosz](http://stackoverflow.com/users/216063/gregory-pakosz): This bug somehow went viral. People keep asking the same questions, having copied these lines without thinking. See e.g. http://stackoverflow.com/questions/12803493/deleteglobalref-crash-on-ics – Alex Cohn Oct 10 '12 at 12:50
1

I was using TurqMage's solution until I tested it on a Android 4.0.3 emulator (Ice Cream Sandwich). For some reason, the call to DeleteGlobalRef fails with a jni warning: JNI WARNING: DeleteGlobalRef on non-global 0x41301ea8 (type=1), followed by a segmentation fault.

I took out the calls to create a NewGlobalRef and DeleteGlobalRef (see below) and it seems to work fine on the Android 4.0.3 emulator.. As it turns out, I'm only using the created byte buffer on the java side, which should hold a java reference to it anyways, so I think the call to NewGlobalRef() was not needed in the first place..

JNIEXPORT jobject JNICALL Java_com_foo_allocNativeBuffer(JNIEnv* env, jobject thiz, jlong size)
{
    void* buffer = malloc(size);
    jobject directBuffer = env->NewDirectByteBuffer(buffer, size);
    return directBuffer;
}

JNIEXPORT void JNICALL Java_comfoo_freeNativeBuffer(JNIEnv* env, jobject thiz, jobject bufferRef)
{
    void *buffer = env->GetDirectBufferAddress(bufferRef);

    free(buffer);
}
Gino
  • 1,343
  • 14
  • 20
0

Use the reflection to call java.nio.DirectByteBuffer.free(). I remind you that Android DVM is inspired by Apache Harmony, which supports the method above.

The direct NIO buffers are allocated on the native heap, not on the Java heap managed by the garbage collection. It's up to the developer to release their native memory. It's a bit different with OpenJDK and Oracle Java because they try to call the garbage collector when the creation of a direct NIO buffer fails but there is no guarantee that it helps.

N.B: You'll have to tinker a bit more if you use asFloatBuffer(), asIntBuffer(), ... because only the direct byte buffer can be "freed".

gouessej
  • 3,297
  • 3
  • 28
  • 55
0

Not sure if your last comments are old or what Kasper. I did the following...

JNIEXPORT jobject JNICALL Java_com_foo_allocNativeBuffer(JNIEnv* env, jobject thiz, jlong size)
{
    void* buffer = malloc(size);
    jobject directBuffer = env->NewDirectByteBuffer(buffer, size);
    jobject globalRef = env->NewGlobalRef(directBuffer);

    return globalRef;
}

JNIEXPORT void JNICALL Java_comfoo_freeNativeBuffer(JNIEnv* env, jobject thiz, jobject globalRef)
{
    void *buffer = env->GetDirectBufferAddress(globalRef);

    env->DeleteGlobalRef(globalRef);
    free(buffer);
}

Then in Java...

mImageData = (ByteBuffer)allocNativeBuffer( mResX * mResY * mBPP );

and

freeNativeBuffer(mImageData);
mImageData = null;

and everything seems to be working fine for me. Thanks a lot Gregory for this idea. The link to the referenced Bug in the JVM has gone bad.

TurqMage
  • 3,333
  • 2
  • 27
  • 52
  • I never managed to get Debug.getNativeHeapAllocatedSize() to report more free memory after the free(). Does it do that for you? I did exactly the same thing as you wrote. In the end I went for a solution which is less memory hungry and forgot about this whole 'alloc/dealloc on JNI side' thing (the whole story has thoroughly convinced me that garbage collection is a bad thing, but that's a different story...) – Kasper Peeters Mar 15 '11 at 09:08
  • Yep I was having the same problem where getNativeHeapAllocatedSize() would never go down. When I put that code in the Alloc'd size dropped as one would expect. I am compiling to SDK 2.1 with NDK R5 and running on an HTC Incredible that is running Android 2.1. – TurqMage Mar 15 '11 at 15:46
  • Were you changing the ByteBuffer to another buffer? I just ran into this problem. I was returning ByteBuffers, using .asIntBuffer and storing them only as IntBuffers. When it came time to free the buffers the GlobalRefs wouldn't free correctly. Keeping the reference to the original ByteBuffer and freeing that fixed the problem. – TurqMage Mar 15 '11 at 18:34
  • @TurqMage Only the real direct byte buffer can be freed, look at the source code of OpenJDK and Apache Harmony to understand why. When you create a view on a direct byte buffer, only the viewed buffer really allocates some memory. – gouessej Sep 15 '15 at 13:17