Является ли GC_FOR_ALLOC более «серьезным» при исследовании использования памяти?

В настоящее время я изучаю проблемы с сборкой мусора с моим Android-приложением, и мне любопытно узнать, указывает ли GC_FOR_ALLOC большую проблему, чем другие сообщения GC, такие как GC_CONCURRENT.

По моему мнению, GC_CONCURRENT делает то, что должен делать сборщик мусора. Куча достигла определенного предела, лучше очистите память.

GC_FOR_ALLOC предлагает мне что-то более серьезное, если я пытаюсь создать объект, и нет памяти, чтобы это сделать.

Существует ли приоритет или «серьезность» для сообщений GC?

В некотором смысле GC_FOR_ALLOC более серьезен, чем GC_CONCURRENT , поскольку GC_FOR_ALLOC означает, что для выполнения запроса на распределение не хватает свободной памяти, поэтому сбор мусора необходим, тогда как GC_CONCURRENT просто означает, что GC чувствовал себя бегущим, как правило, потому что количество свободных После распределения было меньше определенного порога.

GC_FOR_ALLOC сам по себе не является признаком проблемы в вашем приложении:

  • Приложения для Android начинаются с небольшой кучи, которая растет (вплоть до точки), когда приложения требуют больше и больше памяти, а GC_FOR_ALLOC выполняется до увеличения размера кучи. В этом случае GC_FOR_ALLOC абсолютно нормален.
  • Если вы выделяете память быстрее, чем у параллельного GC есть время, чтобы освободить его, GC_FOR_ALLOC неизбежен. И нет ничего неправильного в распределении памяти быстрее, чем параллельный GC может освободить память.

Более серьезным типом GC на Android является GC_BEFORE_OOM , который выполняется, когда запрос на распределение выходит из строя даже после GC_FOR_ALLOC и когда куча приложения выросла настолько, насколько это разрешено. Когда это произойдет, в крайнем случае, Dalvik попытается выпустить SoftReferences, прежде чем делать окончательную попытку выделить память, и если это не сработает, исключите исключение OutOfMemory.

Если вам интересно посмотреть на код для этой логики, то в tryMalloc() в dalvik.git / vm / alloc / Heap.cpp

В любом случае, если вы не возражаете, я сомневаюсь, что просмотр вывода logcat является наиболее эффективным способом отладки проблем с сборкой мусора. Я не знаю, какую конкретную проблему вы испытываете, но вы изучили такие инструменты, как Tracker Allocation Tracker в DDMS и анализ дампов кучи с помощью инструмента hprof-conv ? (Например, для начала см. http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html ).