-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AndroidNativeBufferAllocator memory leak #1990
Comments
In the below link, you can find out why direct byte buffers allocated via JNI |
By "cleaned" you mean that the corresponding native objects are freed? |
I do not know much about JNI. At this point, my knowledge is limited to what was mentioned in the above link. It says a The relevant source from DirectByteBuffer I get from OpenJDK 20. Here is what the cleaner does:
|
I believe this issue cannot be fixed without hooking JNI implementation to GC, we cannot utilize I am trying to get the |
For regular Java-managed direct buffers, JME does not need to clean them up as the GC will clean them up.
For any memory that Java is not allocating, special support (like PhantomReference) will have to be used to make sure to free the native memory.
I think until we switch to using
jme3-alloc
(in JME 3.7), for JME 3.6.1 we should either switch to using PrimitiveAllocator on Android or use PhantomReference in AndroidNativeBufferAllocator to free memory. (similar to thejme3-lwjgl3
buffer allocator)The text was updated successfully, but these errors were encountered: