Ist GC_FOR_ALLOC "ernster" bei der Untersuchung der Speichernutzung?

Question

Ich untersuche gerade Garbage-Collection-Probleme mit meiner Android-App, und ich bin gespannt, ob GC_FOR_ALLOC auf ein größeres Problem hinweist als andere GC-Nachrichten wie GC_CONCURRENT.

Von meinem Verständnis, GC_CONCURRENT macht was der Garbage Collector tun sollte. Der Heap hat eine bestimmte Grenze erreicht, besser Speicher aufräumen.

GC_FOR_ALLOC schlägt vor, dass etwas Ernsteres passiert, wenn ich versuche, ein Objekt zu erstellen, und es gibt keine Speicher mehr, um es zu tun.

Gibt es eine Prioritäts- oder "Seriousness" -Niveau für die GC-Nachrichten?

Answer 1

In gewissem Sinne ist GC_FOR_ALLOC ernster als GC_CONCURRENT, weil GC_FOR_ALLOC bedeutet, dass es nicht genügend freier Speicher war eine Zuordnungsanforderung zu erfüllen, so dass eine Garbage Collection erforderlich war, während GC_CONCURRENT bedeutet nur, dass die GC wie Laufen fühlten, in der Regel, weil die Menge an freiem Speicher wurde nach einer Zuweisung niedriger als ein bestimmter Schwellenwert.

A GC_FOR_ALLOC ist für sich allein kein Zeichen für ein Problem in der Anwendung jedoch:

• Android-Anwendungen mit einem kleinen Haufen beginnen, die (bis zu einem Punkt) wachsen, wenn Anwendungen mehr und mehr Speicher benötigen, und a GC_FOR_ALLOC wird durchgeführt, bevor die Größe des Heapspeichers erhöht wird. In diesem Fall ist GC_FOR_ALLOC völlig normal.
• Wenn Sie Speicher schneller reservieren, als der gleichzeitige GC Zeit hat, um es freizugeben, GC_FOR_ALLOC ist unvermeidlich. Und es ist nichts an sich falsch, Speicher schneller zuzuordnen, als der gleichzeitige GC Speicher freigeben kann.

Eine ernstere Art von GC auf Android ist GC_BEFORE_OOM, die ausgeführt wird, wenn eine Zuweisungsanforderung fehlschlägt auch nach GC_FOR_ALLOC und wenn die Anwendung Haufen so groß geworden ist, wie es sein darf. Wenn dies geschieht, wird Dalvik als letzten Ausweg versuchen, auch SoftReferences zu veröffentlichen, bevor ein letzter Versuch unternommen wird, Speicher zuzuordnen, und wenn dies fehlschlägt, wird eine OutOfMemory-Ausnahme ausgelöst.

Wenn Sie neugierig sind für diese Logik auf den Code zu suchen, ist es in tryMalloc() in dalvik.git/vm/alloc/Heap.cpp

Wie auch immer, wenn Sie nichts dagegen haben, bezweifle ich, dass bei logcat Ausgang suchen, ist der effizienteste Weg, um debuggen Sie Ihre Garbage Collection-Probleme. Ich weiß nicht, welches spezifische Problem Sie haben, aber haben Sie in Tools wie dem Allocation Tracker in DDMS und Analysieren von Heap-Dumps mit Hilfe des Tools hprof-conv nachgeschaut? (Siehe zum Beispiel http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html, um anzufangen.)