Types Of Memory Leaks In A Garbage-collected Language Running In Virtual Machines (ie, Dalvik)
Solution 1:
There is very few memory leak bugs in the runtime, basically because there is very few collections which are the main source of such bugs.
You would use a memory profile to find such a memory leak. You can use VisualVM for small heap dumps but for larger heaps I use a commercial profiler like YourKit.
Solution 2:
As I know, poor user code is the main problem for leading memory leak. And In Dalvik, the java-heap uses dlmalloc for allocing memory, this may lead more Memory fragmentation; even if you call GC, the VM may not trim the java-heap because of 4K per page in Linux being the basic unit. So the android low ram page(http://developer.android.com/training/articles/memory.html) suggests us to alloc/free objects at same time for more continuous memory, and this looks like Generational memory management by hand(http://developer.android.com/training/articles/memory.html#AllocatingRAM).
User code memory leak can be analysis by MAT tool. Trying to understand Dalvikvm and memory leaks
Solution 3:
If you are using a well established language/virtual machine then leaks due to "bugs in the runtime" are extremely unlikely. Spend your time looking for misuse of references in your application code.
Post a Comment for "Types Of Memory Leaks In A Garbage-collected Language Running In Virtual Machines (ie, Dalvik)"