Développement Java
  1. Développement Java
  3. GC_FOR_ALLOC est-il plus «sérieux» lors de la recherche sur l’utilisation de la mémoire?
Intereting Posts
Résoudre plusieurs liaisons SLF4J dans le projet maven Quel type de solution est thymeleaf? Option «Mettre à jour les ressources» manquante dans IntelliJ IDEA Comment obtenir la taille d’une clé RSA en Java Plusieurs méthodes main () en java Refactoring grand object de données Android ne crée pas de fichier StAX – Définition de la version et du codage à l’aide de XMLStreamWriter System.out.print () n’envoie aucune sortie à la console Eclipse. Pourquoi? Configurez Spring Security pour qu’il utilise un fichier UsernamePasswordAuthenticationFilter personnalisé. Existe-t-il des aperçus de la goyave? Java SimpleDateFormat Timezone offset avec les minutes séparées par deux points Pouvons-nous choisir les plugins à charger dans Eclipse au démarrage? Si une interface de marqueur n’a pas de méthode, comment ça marche? Performances de la génération d’UUID aléatoire avec Java 7 ou Java 6

GC_FOR_ALLOC est-il plus «sérieux» lors de la recherche sur l’utilisation de la mémoire?

J’enquête actuellement sur des problèmes de ramassage des ordures avec mon application Android et je suis curieux de savoir si GC_FOR_ALLOC indique un problème plus grave que d’autres messages du GC, tels que GC_CONCURRENT.

De ma compréhension, GC_CONCURRENT fait ce que le ramasse-miettes doit faire. Le tas a atteint une limite particulière, mieux vaut nettoyer la mémoire.

GC_FOR_ALLOC me suggère que quelque chose de plus grave se produit si j’essaie de créer un object et qu’il ne rest plus de mémoire pour le faire.

Existe-t-il une priorité ou un niveau de «gravité» pour les messages du GC?

Dans un sens, GC_FOR_ALLOC est plus grave que GC_CONCURRENT , car GC_FOR_ALLOC signifie qu’il n’y avait pas assez de mémoire disponible pour répondre à une demande d’allocation. Un garbage collection était donc nécessaire. la mémoire est devenue inférieure à un certain seuil après une allocation.

Un GC_FOR_ALLOC n’est pas en soi un signe de problème dans votre application, cependant:

  • Les applications Android commencent par un petit tas qui augmente (jusqu’à un point) lorsque les applications nécessitent de plus en plus de mémoire. Un GC_FOR_ALLOC est effectué avant d’augmenter la taille du tas. Dans ce cas, GC_FOR_ALLOC est parfaitement normal.
  • Si vous allouez de la mémoire plus rapidement que le GC simultané n’a le temps de la libérer, GC_FOR_ALLOC est inévitable. Et il n’y a rien de mal à allouer de la mémoire plus rapidement que le GC simultané ne peut libérer de la mémoire.

GC_BEFORE_OOM est un type de GC plus sérieux sur Android, qui est exécuté lorsqu’une demande d’allocation échoue même après GC_FOR_ALLOC et lorsque le GC_FOR_ALLOC application a atteint la taille GC_FOR_ALLOC autorisée. Lorsque cela se produit, Dalvik essaiera également de libérer SoftReferences avant de tenter une dernière fois d’allouer de la mémoire. Si cela échoue, émettez une exception OutOfMemory.

Si vous êtes curieux de voir le code de cette logique, vous le tryMalloc() dans tryMalloc() dans dalvik.git / vm / alloc / Heap.cpp

Quoi qu’il en soit, si vous le permettez, je doute que le fait de regarder la sortie logcat soit le moyen le plus efficace de déboguer vos problèmes de récupération de place. Je ne sais pas quel problème spécifique vous rencontrez, mais avez-vous déjà examiné des outils tels que le hprof-conv allocation dans DDMS et analysé les hprof-conv à l’aide de l’outil hprof-conv ? (Voir http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html pour commencer, par exemple.)