2

I am new to android programming. The memory consumption of may android app increases significantly over time. When analyzed through MAT, it shows the objects being piled up whose GC root is Native Stack. Those objects are being referenced as global ref in native code, but properly being released over time I have also put logs to make sure the count matches. The documentation about native stack is not much clear as it just states:

In or out parameters in native code, such as user defined JNI code or JVM internal code. This is often the case as many methods have native parts and the objects handled as method parameters become GC roots. For example, parameters used for file/network I/O methods or reflection.

I am not quite sure what it says, where is the problem and how can I fix it. Any hints are much appreciated. Thanks in advance.

FD_
  • 12,947
  • 4
  • 35
  • 62
Aarkan
  • 3,811
  • 6
  • 40
  • 54
  • Here are a couple of links that might be helpful: http://yourkit.com/docs/75/help/performance_problems/memory_leaks/gc_roots.jsp , http://www.youtube.com/watch?v=_CruQY55HOk – Submersed Feb 05 '14 at 18:38
  • Useful intro to local vs. global references in JNI: http://developer.android.com/training/articles/perf-jni.html#local_and_global_references . – fadden Feb 05 '14 at 20:41

1 Answers1

1

This answer won't give you a definitive solution, not because I'm not willing, but because it's impossible (and even harder without not just viewing your code, but knowing very well your code). But from my experience I can tell you that those kind of memory leaks doesn't occur just due to directly referenced objects - objects you declare (and keep referencing another classes/objects) in turn depends on many other classes and so on, and probably you're seeing a memory leak due to an incorrect handling of any of your instances which at the same time reference to other instances.

Debugging memory leaks is a often a very hard work, not just because as I said above it sometimes doesn't depend directly on what you've declared, but also because finding a solution might not be trivial. The best thing you can do is what you already seem to be doing: DDMS + HPROF. I don't know how much knowledge you have, but although it's not a universal method, this link helped me so much to find memory leaks in my code.

Although it seems trivial, the best way to debug those kind of things is progresively remove portions of your code (overall, those which implies working with instances of other classes) and see how the HPROF report change.

---- EDIT ----

This question on SO is a good example to illustrate the GC roots.

Community
  • 1
  • 1
nKn
  • 13,691
  • 9
  • 45
  • 62
  • +1 for the link. But could you please help me in understanding the meaning of GC root as Native Stack? What does it mean? – Aarkan Feb 05 '14 at 18:21
  • As I understand it, there's some situations (mostly controllable) when some object you're handling becomes accesible from outside the heap. That basically means you're locking some part of the hierarchy which gets allocated and cannot be freed, but sometimes it doesn't mean you're directly referencing them. The two examples you've quoted, JVM and JNI make reference to virtual machines and interacting with other languages respectively - using these in some circumstances may lead to making them GC roots and became huge memory leak productors, as they may not be freed. – nKn Feb 05 '14 at 18:37
  • Added a useful link in my answer. – nKn Feb 05 '14 at 18:39