Skip to content Skip to sidebar Skip to footer

Types Of Memory Leaks In A Garbage-collected Language Running In Virtual Machines (ie, Dalvik)

Aren't there two types of memory leaks when dealing with a garbage collected language: user-coded and runtime-environment? That is, poor user code (say lots of global static refere

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)"