This is about Android. The situation:
C++ library and java wrapper classes plus native functions (JNI) for working with C++ classes from the library. When common java code needs C++ object, it creates corresponding java wrapper object which creates C++ object through native function and remembers the pointer to the native object in 'long' variable. In all next actions the wrapper gives this pointer to the native functions etc.
The problem:
How to release all allocated C++ objects at the end? Currently every wrapper class has 'finalize' method where it calls native function for releasing of the C++ object, but Android doesn't guarantee the calling of 'finalize'! At the other side, normally the C++ library has no idea how many and what types of C++ objects are allocated by java code.
What will happens with the remaining allocated memory when our java application terminates, will Android release automatically the whole heap, used from the native library, when the OS unloads the library?
At the end of the process lifetime, all process memory (both Java and C++ heap) will be freed and reclaimed by the system. One thing is though, Android activity closing does not necessarily end the process. I'm not sure what's the process shutdown policy there.
On the other hand, relying on the garbage collection and finalize() sounds like solid design to me. You claim - "Android does not guarantee finalize()". Do you have a cite for that? 'Cause if it comes with a disclaimer of "when the object is freed as a part of process shutdown...", then we're still good.
And if you're super-paranoid, you can write your own malloc()/free()/realloc() wrapper, store a list of all allocated objects, and introduce a cleanup function that walks the list and frees them all. The containing Java objects, however, might end in a weird zombie state where the memory has been freed from under them. This is a tricky proposition that is very easy to get wrong. So I'd still say - have faith in the garbage collector. Lack thereof would be... disturbing.
Due to the difference in paradigms, you have to incorporate explicit destruction into your Java objects that are implemented under the hood using C++ resources. So a close() or other such method. The same issue comes up with the JNI, so answers to those questions will apply to you:
Force Java to call my C++ destructor (JNI)
As for the memory issue on closing, it's generally best in my opinion to not rely on this. If you get to a clean state, valgrind and such can make sure you weren't leaking.
But from a technical standpoint--since Android is based on Linux, I'd imagine it does the usual thing and will free all the memory when the process closes. Taking advantage of that can make your program exit faster than explicitly freeing memory (for experts only who use other methods to ensure this maintains program correctness and they aren't leaking at runtime).
We are using JNIs and we had a problem like that
Actually, the problem resided in the fact that we were overloading finalize() to do the clean up. We solved our problems by removing our finalize() and creating a clean() instead. This clean() calls the JNI function that does the appropriate deletes (and set the C++ pointers to null, just in case). We call clean() just as you would in C++ with delete (e.g. when the variable goes out of scope).
That worked for us. I hope it works for you. Good luck!
Related
I cannot find any references to a detailed explanation about how JNI works on Android in detail, so:
Since every Android application runs in its own process, with its own instance of the Dalvik/ART virtual machine, I think that the native code will be executed in the same process, am I right?
I read that when the VM invokes a function, it passes a JNIEnv pointer, a jobject pointer, and any Java arguments declared by the Java method.
But how is this made at assembly level (under the hood)?
I read that you can instantiate objects, call methods, and so on, like Reflection, using the functions provided by the JNIEnv. Therefore, my question is: have I a "direct" memory access to the VM or I have always to use the JNIEnv's functions?
The Android JVM is under Apache license, so the best detailed and precise description can be found in the form of source code. Note that there are two different JVMs: dalvik and art. Under the hood they are very different, to the extent that a user of JNI may consider special adaptations.
the native code will be executed in the same process
Exactly. Note that an Android app can run in more than one process, and also it can spawn child processes (normal Unix behavior). But JNI is not IPC.
how is this made at assembly level?
More or less, this is described in a related
question: What does a JVM have to do when calling a native method?
have I a "direct" memory access to the VM?
Yes, you have. There is no security barrier between your C code and the JVM. You can reverse engineer the data structures, and do whatever you like. The exact implementations of the JVM not only depend on the Android version, but may be modified without notice by the vendor, as long as the public API of the JVM (including JNI) is compatible. The chances that you will do something useful with direct memory access to JVM are minimal, but the risk that it will crash is very high.
Note that this is not a security issue: your C code is running in a separate process (with your Java code), and is subject to the same permissions restrictions as the Java code. It has no access to the private memory of other apps or procsses. Whatever you change in your instance of JVM will not effect VM that runs other apps.
I learned recently of an Android library AndFix which allows for live method patching. Now, as far as I know, Dalvik does not allow runtime manipulation of bytecode or dex.
Can someone provide a good explanation on how AndFix does live patching?
Looking at the sources, you can see the patch mechanism for Dalvik here. The dalvik_replaceMethod() function is modifying the internal Dalvik state, changing the Method struct to point to a replacement method.
It doesn't modify the DEX on disk or in memory, just routes the method calls to a replacement method. This approach is highly version-dependent, as changes to Method or the way methods work will break things. Dalvik hasn't changed much since mid-2011, which makes it easy, but if you look at the nearby "art" directory you can see different implementations for each major version of Android.
Let's consider below special case:
Case description:
Java App call jni then native mediaserver to create a instance. This native instance will use about 40M memory.
Java App didn't release this instance but release it in finalize (GC).
If many such instance created by Java App, then the memory in Java is increase but not too much, native instance will occupy N*40M memory, many memory will be consumed by native process if GC not happen in time.
Questions:
For this case, when will GC triggered by Java? Will GC consider the native memory increase then call GC automatically?
Should we call System.gc() in Java layer to release native memory? Someone seems don't agree to call System.gc() by application.
What's best solution to resolve such memory shortage!
Actually, GC is a java layer concept, for native code, no such concept I guess.
We have a large app that's always running into the dread method count limit. I've been asked to come up with a way to let it do much more, including supporting plugins. Looking for ways to unload code, I ran across JNI Tips which says
Classes are only unloaded if all classes associated with a ClassLoader
can be garbage collected, which is rare but will not be impossible in
Android.
This did seem to imply that a plugin can be unloaded if you, say,
use a new DexClassLoader for each .jar file,
only ever refer to the plugin through an interface reference, and
null-out any copies of that interface reference when done.
So, I created a test case:
I created a couple of trivial plugins, using a unique loader for each.
I created a ReferenceQueue<ClassLoader> and created weak references to my two loaders, using that queue; I created/started a thread that loops indefinitely, doing a queue .remove() and reporting.
I similarly created a ReferenceQueue<Class<?>> and created weak references to each plugin's getClass() using the queue; I created/started another thread monitoring the class reference queue.
I create a thousand 1000x1000xARGB_8888 bitmaps to thoroughly force gc.
My monitoring threads seem to work - I saw loader2 get gc-ed when I used loader1 to load both plugins by mistake ;-) - but otherwise my threads stay silent, even on 4.3. Am I maybe missing something obvious in this test case, or is it still the case that the
Dalvik VM doesn't currently unload classes
as Google employee fadden says in Android: When do classes get unloaded by the system?
The Dalvik VM still doesn't unload classes. The JNI Tips page is encouraging good behavior so your app doesn't break if the VM starts unloading classes someday.
I have some confusion about the life cycle of native code in Android aps. I have seen references that say that the native code is executed inside the Dalvik VM, but is that true? I was under the impression that the VM only runs Dalvik bytecode. On the otherhand, the native code uses JNI which is be called from Java inside the VM. Lastly, does the use of NativeActivity make any difference?
I thought I was understanding the NDK fairly well, until I sat down and tried to explain it to myself. I'm not even sure that I'm asking the question in a sensible manner.
I have seen references that say that the native code is executed inside the Dalvik VM, but is that true?
It executes inside a process that contains a Dalvik VM. Personally, I would not describe it as executing inside the VM -- as you say, Dalvik bytecode executes inside the VM. "Under the control of the Dalvik VM" would be better phrasing, IMHO. Of course, it boils down to your definition of "in", I suppose.
Lastly, does the use of NativeActivity make any difference?
Not really, insofar as NativeActivity is implemented in Java. While you may not have any Java, Java is still lightly involved in the act of running your native code.