CODEWITHSUNDEEP
javaandroidgarbage-collectiondalvik
samus
samus

Reputation: 6202

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 references) vs bugs in the runtime, or are they considered one in the same? Are the tools used to find them the same typically?

Upvotes: 1

Views: 110

Answers (3)

QJGui
QJGui

Reputation: 967

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

Upvotes: 1

Dale Wilson
Dale Wilson

Reputation: 9434

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.

Upvotes: 1

Peter Lawrey
Peter Lawrey

Reputation: 533500

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.

Upvotes: 2

Related Questions