GC_FOR_ALLOC è più "serio" quando si esamina l'utilizzo della memoria?

Question

Attualmente sto esaminando i problemi di garbage collection con la mia app per Android, e sono curioso di sapere se GC_FOR_ALLOC è indicativo di un problema più grande di altri messaggi GC, come GC_CONCURRENT.

Dal mio punto di vista, GC_CONCURRENT sta facendo ciò che il garbage collector dovrebbe fare. L'heap ha raggiunto un limite particolare, meglio andare a ripulire la memoria.

GC_FOR_ALLOC mi suggerisce che qualcosa di più serio sta accadendo se sto cercando di creare un oggetto e non c'è più memoria per farlo.

C'è un livello di priorità o di "serietà" per i messaggi del GC?

Answer 1

In un certo senso, GC_FOR_ALLOC è più grave di GC_CONCURRENT, perché GC_FOR_ALLOC significa che non c'erano abbastanza memoria libera per soddisfare una richiesta di allocazione, in modo da una garbage collection era necessario, mentre GC_CONCURRENT significa solo che il GC si sentiva come la corsa, in genere perché la quantità di memoria libera è diventata inferiore a una certa soglia dopo un'allocazione.

Un GC_FOR_ALLOC è di per sé non è un segno di un problema nell'applicazione comunque:

• applicazioni Android iniziano con un mucchietto che cresce (fino a un certo punto), quando le applicazioni richiedono sempre più memoria, e a GC_FOR_ALLOC viene fatto prima di aumentare la dimensione dell'heap. In questo caso GC_FOR_ALLOC è perfettamente normale.
• Se si alloca la memoria più rapidamente di quanto il GC concorrente abbia il tempo di liberarlo, lo è GC_FOR_ALLOC. E non c'è nulla di intrinsecamente sbagliato nell'allocare la memoria più velocemente di quanto il GC concorrente possa liberare memoria.

Un tipo più grave di GC su Android è GC_BEFORE_OOM, che viene eseguita quando una richiesta di allocazione fallisce anche dopo GC_FOR_ALLOC e quando il mucchio domanda è cresciuta grande come è permesso di essere. Quando questo accade, come ultima risorsa, Dalvik proverà a rilasciare anche SoftReferences, prima di fare un ultimo tentativo di allocare memoria e se fallisce lancia un'eccezione OutOfMemory.

Se siete curiosi di guardare il codice per questa logica, è in tryMalloc() in dalvik.git/vm/alloc/Heap.cpp

Comunque, se non ti dispiace, dubito che guardando uscita logcat è il modo più efficace per fai il debug dei tuoi problemi di garbage collection. Non so quale problema specifico si sta avendo, ma hai esaminato strumenti come il Tracker di allocazione in DDMS e analizzando i dump dell'heap con l'aiuto dello strumento hprof-conv? (Per iniziare, vedi http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html.)