En esta página, se describe cómo depurar la recolección de elementos no utilizados de Android Runtime (ART) (GC) problemas de corrección y rendimiento. Explica cómo usar la verificación de GC identificar soluciones para los errores de verificación de GC y medir para abordar los problemas de rendimiento de GC.
Para trabajar con ART, consulta las páginas de ART y Dalvik. y el formato ejecutable Dalvik. Para obtener ayuda adicional sobre cómo verificar el comportamiento de la app, consulta Verificando el comportamiento de la app en el entorno de ejecución de Android (ART)
Descripción general de ART GC
ART tiene algunos planes de recolección de elementos no utilizados diferentes que consisten en ejecutar diferentes recopiladores. A partir de Android 8 (Oreo), el plan predeterminado es Copia simultánea (CC). El otro plan de recolección de elementos no utilizados es el barrido de marcas simultáneo (CMS).
Algunas de las características principales de GC de copia simultánea son las siguientes:
- CC permite usar un asignador de puntero de prioridad llamado RegionTLAB. De esta manera, se asigna un subproceso local búfer de asignación (TLAB) a cada subproceso de la app, que puede asignar objetos fuera de su TLAB si tocas la “parte superior” puntero, sin ninguna sincronización.
- CC realiza la desfragmentación de montón con la copia simultánea de objetos sin pausar los subprocesos de la app. Esto se logra con la ayuda de una barrera de lectura que intercepta las lecturas de referencia del sin la necesidad de que intervenga el desarrollador de la app.
- La GC solo tiene una pequeña pausa, que es constante en el tiempo con respecto al tamaño del montón.
- CC se extiende para ser una recolección de elementos no utilizados en Android 10 y versiones posteriores. Permite recopilar objetos jóvenes, a los que a menudo se vuelve inalcanzable con bastante rapidez, con poco esfuerzo. Esto ayuda ya que aumenta la capacidad de procesamiento de la GC y retrasa considerablemente la necesidad de realizarla.
La otra recolección de elementos no utilizados que ART todavía admite es CMS. Esta La recolección de elementos no utilizados también admite la compactación, pero no de forma simultánea. Se evita la compactación hasta que la app Pasa a segundo plano y, luego, se pausan los subprocesos de la app para realizar la compactación. La compactación también es necesaria cuando una asignación de objeto falla debido a la fragmentación. En este en caso de que la app no responda durante un tiempo.
Dado que el CMS rara vez se compacta y, por lo tanto, los objetos libres pueden no ser contiguos, utiliza un basado en listas libres llamado RosAlloc. Tiene un costo de asignación más alto que el a RegionTLAB. Por último, debido a la fragmentación interna, el uso de memoria del montón de Java puede ser mayor para CMS que para CC.
Verificación de GC y opciones de rendimiento
Cambiar el tipo de recolección de elementos no utilizados
Los OEM pueden cambiar el tipo de GC. El proceso de cambio
implica configurar la variable de entorno ART_USE_READ_BARRIER durante el tiempo de compilación.
El valor predeterminado es verdadero, lo que habilita el colector de CC, ya que usa la barrera de lectura. Para CMS, este
variable debe configurarse explícitamente como false.
De forma predeterminada, el colector de CC se ejecuta en modo generacional en Android 10 y versiones posteriores. Para
inhabilitar el modo generacional, el argumento de línea de comandos -Xgc:nogenerational_cc se puede
que se usan. Como alternativa, la propiedad del sistema se puede establecer de la siguiente manera:
adb shell setprop dalvik.vm.gctype nogenerational_ccEl colector de CMS siempre se ejecuta en modo generacional.
Cómo verificar el montón
La verificación de montón es probablemente la opción de recolección de elementos no utilizados más útil para la depuración
Errores relacionados con la GC o daños en el montón. Habilitar la verificación de montón provoca la GC
para comprobar la precisión del montón en algunos puntos durante el proceso
de recopilación de imágenes. La verificación de montón comparte las mismas opciones que las que
cambiar el tipo de GC. Si se habilita esta opción, la verificación del montón verifica las raíces y
garantiza que los objetos accesibles solo hagan referencia a otros objetos accesibles. recolección de elementos no utilizados
la verificación se habilita pasando los siguientes valores de -Xgc:
- Si se habilita,
[no]preverifyrealiza una verificación del montón antes de iniciar la recolección de elementos no utilizados. - Si se habilita,
[no]presweepingverifyrealiza la verificación del montón. antes de iniciar el proceso de barrido con recolector de basura. - Si se habilita,
[no]postverifyrealiza la verificación del montón después de de que la recolección de elementos no utilizados termine de barrer. [no]preverify_rosalloc,[no]postsweepingverify_rosallocy[no]postverify_rosallocson opciones adicionales de recolección de elementos no utilizados que verifican solo el estado de la contabilidad interna de RosAlloc. Por lo tanto, solo son aplicables el recopilador CMS, que usa el asignador RosAlloc. Los aspectos principales que se verifican son que los valores mágicos coincidan con las constantes esperadas y que los bloques libres de memoria registrados en el mapa defree_page_runs_.
Rendimiento
Existen dos herramientas principales para medir el rendimiento de la recolección de elementos no utilizados: tiempo de la recolección de elementos no utilizados de volcados de software y Systrace. También hay una versión avanzada de Systrace que se llama Perfetto. Forma visual de medir los problemas de rendimiento del GC es usar Systrace y Perfetto para determinar qué GC causan pausas prolongadas o interrumpir los subprocesos de la app. Aunque ART GC ha mejorado significativamente con el tiempo, el mutador incorrecto de la aplicación, como una asignación excesiva, puede causar problemas de rendimiento.
Estrategia de recopilación
La recolección de elementos no utilizados de CC se recopila mediante la ejecución de una recolección de elementos no utilizados reciente o una recolección de elementos no utilizados de montón completo. Idealmente, el GC joven se ejecuta con más frecuencia. La recolección de elementos no utilizados realiza recopilaciones de CC jóvenes hasta la capacidad de procesamiento (calculada en bytes liberados por segundo de la duración de la recolección de elementos no utilizados) del ciclo de recolección recién finalizado es menor que la capacidad de procesamiento promedio de colecciones de CC de montón completo. Cuando esto ocurre, se elige el CC del montón completo para la siguiente GC simultánea en lugar de CC jóvenes. Una vez que se complete la recolección del montón, la siguiente La recolección de elementos no usados se vuelve a cambiar a CC joven. Un factor clave que hace que esta estrategia funcione es que los jóvenes CC no ajusta el límite de huella de montón una vez finalizado. Esto provoca que el CC joven hasta que la capacidad de procesamiento sea menor que la CC del montón completo, por lo que el montón crece.
Usa SIGQUIT para obtener información de rendimiento de GC
Para obtener los tiempos de rendimiento de la recolección de elementos no utilizados de las apps, envía SIGQUIT a
que ya están ejecutando apps o pasar -XX:DumpGCPerformanceOnShutdown
a dalvikvm cuando inicias un programa de línea de comandos. Cuando una app se pone
el indicador de solicitud de ANR (SIGQUIT), vuelca la información relacionada con sus bloqueos
pilas de subprocesos
y rendimiento de la GC.
Para obtener volcados de sincronización de GC, usa lo siguiente:
adb shell kill -s QUIT PID
Esto crea un archivo (con la fecha y la hora en el nombre, como anr_2020-07-13-19-23-39-817).
en /data/anr/. Esta
contiene algunos volcados de ANR, así como tiempos de GC. Puedes ubicar el
Tiempos de recolección de elementos no utilizados buscando Volcado de tiempos de GC acumulativos Estos horarios
mostrar algunos datos que pueden ser de interés, como la información del histograma de
para las fases y pausas de cada tipo de GC. Por lo general, es más importante observar las pausas
. Por ejemplo:
young concurrent copying paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms
Esto muestra que la pausa promedio fue de 1.83 ms, que debería ser lo suficientemente baja como para no se perderán fotogramas en la mayoría de las apps y no debería ser un problema.
Otra área de interés es el momento de la suspensión, que mide cuánto tiempo le toma a un subproceso alcanzar un punto de suspensión después de que la GC solicita se suspende. Este tiempo se incluye en las pausas de recolección de elementos no utilizados, por lo que es útil determinar si las pausas largas se deben a que la recolección de elementos no utilizados es lenta o que el subproceso se suspende lentamente. Este es un ejemplo de un momento normal para la suspensión en un Nexus 5:
suspend all histogram: Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us
Hay otras áreas de interés, como el tiempo total empleado y la recolección de elementos no utilizados de procesamiento. Ejemplos:
Total time spent in GC: 502.251ms Mean GC size throughput: 92MB/s Mean GC object throughput: 1.54702e+06 objects/s
Este es un ejemplo de cómo volcar los tiempos de la recolección de elementos no utilizados de una app que ya está en ejecución:
adb shell kill -s QUIT PIDadb pull /data/anr/anr_2020-07-13-19-23-39-817
En este punto, los tiempos de la recolección de elementos no utilizados están dentro de anr_2020-07-13-19-23-39-817. Este es un resultado de ejemplo
desde Google Maps:
Start Dumping histograms for 2195 iterations for concurrent copying MarkingPhase: Sum: 258.127s 99% C.I. 58.854ms-352.575ms Avg: 117.651ms Max: 641.940ms ScanCardsForSpace: Sum: 85.966s 99% C.I. 15.121ms-112.080ms Avg: 39.164ms Max: 662.555ms ScanImmuneSpaces: Sum: 79.066s 99% C.I. 7.614ms-57.658ms Avg: 18.014ms Max: 546.276ms ProcessMarkStack: Sum: 49.308s 99% C.I. 6.439ms-81.640ms Avg: 22.464ms Max: 638.448ms ClearFromSpace: Sum: 35.068s 99% C.I. 6.522ms-40.040ms Avg: 15.976ms Max: 633.665ms SweepSystemWeaks: Sum: 14.209s 99% C.I. 3.224ms-15.210ms Avg: 6.473ms Max: 201.738ms CaptureThreadRootsForMarking: Sum: 11.067s 99% C.I. 0.835ms-13.902ms Avg: 5.044ms Max: 25.565ms VisitConcurrentRoots: Sum: 8.588s 99% C.I. 1.260ms-8.547ms Avg: 1.956ms Max: 231.593ms ProcessReferences: Sum: 7.868s 99% C.I. 0.002ms-8.336ms Avg: 1.792ms Max: 17.376ms EnqueueFinalizerReferences: Sum: 3.976s 99% C.I. 0.691ms-8.005ms Avg: 1.811ms Max: 16.540ms GrayAllDirtyImmuneObjects: Sum: 3.721s 99% C.I. 0.622ms-6.702ms Avg: 1.695ms Max: 14.893ms SweepLargeObjects: Sum: 3.202s 99% C.I. 0.032ms-6.388ms Avg: 1.458ms Max: 549.851ms FlipOtherThreads: Sum: 2.265s 99% C.I. 0.487ms-3.702ms Avg: 1.031ms Max: 6.327ms VisitNonThreadRoots: Sum: 1.883s 99% C.I. 45us-3207.333us Avg: 429.210us Max: 27524us InitializePhase: Sum: 1.624s 99% C.I. 231.171us-2751.250us Avg: 740.220us Max: 6961us ForwardSoftReferences: Sum: 1.071s 99% C.I. 215.113us-2175.625us Avg: 488.362us Max: 7441us ReclaimPhase: Sum: 490.854ms 99% C.I. 32.029us-6373.807us Avg: 223.623us Max: 362851us EmptyRBMarkBitStack: Sum: 479.736ms 99% C.I. 11us-3202.500us Avg: 218.558us Max: 13652us CopyingPhase: Sum: 399.163ms 99% C.I. 24us-4602.500us Avg: 181.851us Max: 22865us ThreadListFlip: Sum: 295.609ms 99% C.I. 15us-2134.999us Avg: 134.673us Max: 13578us ResumeRunnableThreads: Sum: 238.329ms 99% C.I. 5us-2351.250us Avg: 108.578us Max: 10539us ResumeOtherThreads: Sum: 207.915ms 99% C.I. 1.072us-3602.499us Avg: 94.722us Max: 14179us RecordFree: Sum: 188.009ms 99% C.I. 64us-312.812us Avg: 85.653us Max: 2709us MarkZygoteLargeObjects: Sum: 133.301ms 99% C.I. 12us-734.999us Avg: 60.729us Max: 10169us MarkStackAsLive: Sum: 127.554ms 99% C.I. 13us-417.083us Avg: 58.111us Max: 1728us FlipThreadRoots: Sum: 126.119ms 99% C.I. 1.028us-3202.499us Avg: 57.457us Max: 11412us SweepAllocSpace: Sum: 117.761ms 99% C.I. 24us-400.624us Avg: 53.649us Max: 1541us SwapBitmaps: Sum: 56.301ms 99% C.I. 10us-125.312us Avg: 25.649us Max: 1475us (Paused)GrayAllNewlyDirtyImmuneObjects: Sum: 33.047ms 99% C.I. 9us-49.931us Avg: 15.055us Max: 72us (Paused)SetFromSpace: Sum: 11.651ms 99% C.I. 2us-49.772us Avg: 5.307us Max: 71us (Paused)FlipCallback: Sum: 7.693ms 99% C.I. 2us-32us Avg: 3.504us Max: 32us (Paused)ClearCards: Sum: 6.371ms 99% C.I. 250ns-49753ns Avg: 207ns Max: 188000ns Sweep: Sum: 5.793ms 99% C.I. 1us-49.818us Avg: 2.639us Max: 93us UnBindBitmaps: Sum: 5.255ms 99% C.I. 1us-31us Avg: 2.394us Max: 31us Done Dumping histograms concurrent copying paused: Sum: 315.249ms 99% C.I. 49us-1378.125us Avg: 143.621us Max: 7722us concurrent copying freed-bytes: Avg: 34MB Max: 54MB Min: 2062KB Freed-bytes histogram: 0:4,5120:5,10240:19,15360:69,20480:167,25600:364,30720:529,35840:405,40960:284,46080:311,51200:38 concurrent copying total time: 569.947s mean time: 259.657ms concurrent copying freed: 1453160493 objects with total size 74GB concurrent copying throughput: 2.54964e+06/s / 134MB/s per cpu-time: 157655668/s / 150MB/s Average major GC reclaim bytes ratio 0.486928 over 2195 GC cycles Average major GC copied live bytes ratio 0.0894662 over 2199 major GCs Cumulative bytes moved 6586367960 Cumulative objects moved 127490240 Peak regions allocated 376 (94MB) / 2048 (512MB) Start Dumping histograms for 685 iterations for young concurrent copying ScanCardsForSpace: Sum: 26.288s 99% C.I. 8.617ms-77.759ms Avg: 38.377ms Max: 432.991ms ProcessMarkStack: Sum: 21.829s 99% C.I. 2.116ms-71.119ms Avg: 31.868ms Max: 98.679ms ClearFromSpace: Sum: 19.420s 99% C.I. 5.480ms-50.293ms Avg: 28.351ms Max: 507.330ms ScanImmuneSpaces: Sum: 9.968s 99% C.I. 8.155ms-30.639ms Avg: 14.552ms Max: 46.676ms SweepSystemWeaks: Sum: 6.741s 99% C.I. 3.655ms-14.715ms Avg: 9.841ms Max: 22.142ms GrayAllDirtyImmuneObjects: Sum: 4.466s 99% C.I. 0.584ms-14.315ms Avg: 6.519ms Max: 24.355ms FlipOtherThreads: Sum: 3.672s 99% C.I. 0.631ms-16.630ms Avg: 5.361ms Max: 18.513ms ProcessReferences: Sum: 2.806s 99% C.I. 0.001ms-9.459ms Avg: 2.048ms Max: 11.951ms EnqueueFinalizerReferences: Sum: 1.857s 99% C.I. 0.424ms-8.609ms Avg: 2.711ms Max: 24.063ms VisitConcurrentRoots: Sum: 1.094s 99% C.I. 1.306ms-5.357ms Avg: 1.598ms Max: 6.831ms SweepArray: Sum: 711.032ms 99% C.I. 0.022ms-3.502ms Avg: 1.038ms Max: 7.307ms InitializePhase: Sum: 667.346ms 99% C.I. 303us-2643.749us Avg: 974.227us Max: 3199us VisitNonThreadRoots: Sum: 388.145ms 99% C.I. 103.911us-1385.833us Avg: 566.635us Max: 5374us ThreadListFlip: Sum: 202.730ms 99% C.I. 18us-2414.999us Avg: 295.956us Max: 6780us EmptyRBMarkBitStack: Sum: 132.934ms 99% C.I. 8us-1757.499us Avg: 194.064us Max: 8495us ResumeRunnableThreads: Sum: 109.593ms 99% C.I. 6us-4719.999us Avg: 159.989us Max: 11106us ResumeOtherThreads: Sum: 86.733ms 99% C.I. 3us-4114.999us Avg: 126.617us Max: 19332us ForwardSoftReferences: Sum: 69.686ms 99% C.I. 14us-2014.999us Avg: 101.731us Max: 4723us RecordFree: Sum: 58.889ms 99% C.I. 0.500us-185.833us Avg: 42.984us Max: 769us FlipThreadRoots: Sum: 58.540ms 99% C.I. 1.034us-4314.999us Avg: 85.459us Max: 10224us CopyingPhase: Sum: 52.227ms 99% C.I. 26us-728.749us Avg: 76.243us Max: 2060us ReclaimPhase: Sum: 37.207ms 99% C.I. 7us-2322.499us Avg: 54.316us Max: 3826us (Paused)GrayAllNewlyDirtyImmuneObjects: Sum: 23.859ms 99% C.I. 11us-98.917us Avg: 34.830us Max: 128us FreeList: Sum: 20.376ms 99% C.I. 2us-188.875us Avg: 29.573us Max: 998us MarkZygoteLargeObjects: Sum: 18.970ms 99% C.I. 4us-115.749us Avg: 27.693us Max: 122us (Paused)SetFromSpace: Sum: 12.331ms 99% C.I. 3us-94.226us Avg: 18.001us Max: 109us SwapBitmaps: Sum: 11.761ms 99% C.I. 5us-49.968us Avg: 17.169us Max: 67us ResetStack: Sum: 4.317ms 99% C.I. 1us-64.374us Avg: 6.302us Max: 190us UnBindBitmaps: Sum: 3.803ms 99% C.I. 4us-49.822us Avg: 5.551us Max: 70us (Paused)ClearCards: Sum: 3.336ms 99% C.I. 250ns-7000ns Avg: 347ns Max: 7000ns (Paused)FlipCallback: Sum: 3.082ms 99% C.I. 1us-30us Avg: 4.499us Max: 30us Done Dumping histograms young concurrent copying paused: Sum: 229.314ms 99% C.I. 37us-2287.499us Avg: 334.764us Max: 6850us young concurrent copying freed-bytes: Avg: 44MB Max: 50MB Min: 9132KB Freed-bytes histogram: 5120:1,15360:1,20480:6,25600:1,30720:1,35840:9,40960:235,46080:427,51200:4 young concurrent copying total time: 100.823s mean time: 147.187ms young concurrent copying freed: 519927309 objects with total size 30GB young concurrent copying throughput: 5.15683e+06/s / 304MB/s per cpu-time: 333152554/s / 317MB/s Average minor GC reclaim bytes ratio 0.52381 over 685 GC cycles Average minor GC copied live bytes ratio 0.0512109 over 685 minor GCs Cumulative bytes moved 1542000944 Cumulative objects moved 28393168 Peak regions allocated 376 (94MB) / 2048 (512MB) Total time spent in GC: 670.771s Mean GC size throughput: 159MB/s per cpu-time: 177MB/s Mean GC object throughput: 2.94152e+06 objects/s Total number of allocations 1974199562 Total bytes allocated 104GB Total bytes freed 104GB Free memory 10MB Free memory until GC 10MB Free memory until OOME 442MB Total memory 80MB Max memory 512MB Zygote space size 2780KB Total mutator paused time: 544.563ms Total time waiting for GC to complete: 117.494ms Total GC count: 2880 Total GC time: 670.771s Total blocking GC count: 1 Total blocking GC time: 86.373ms Histogram of GC count per 10000 ms: 0:259879,1:2828,2:24,3:1 Histogram of blocking GC count per 10000 ms: 0:262731,1:1 Native bytes total: 30599192 registered: 8947416 Total native bytes at last GC: 30344912
Herramientas para analizar problemas de corrección del GC
Hay varios factores que pueden causar fallas dentro del ART. Fallas que leer o escribir en campos de objetos puede indicar daños en el montón. Si el botón La GC falla cuando se está ejecutando, también podría apuntar a daños en el montón. La causa más común de los daños en el montón es el código incorrecto de la app. Afortunadamente, existen herramientas para Depurar fallas relacionadas con el GC y el montón, incluidas las opciones de verificación de montón especificadas y CheckJNI.
ComprobarJNI
CheckJNI es un modo que agrega verificaciones de JNI para verificar el comportamiento de la app. no las habilita de forma predeterminada por motivos de rendimiento. Las comprobaciones detectan algunos errores que pueden provocar daños en el montón. como el uso de referencias globales y locales no válidas o inactivas. Para habilitar CheckJNI:
adb shell setprop dalvik.vm.checkjni true
El modo forcecopy de CheckJNI es útil para detectar escritura después del final de las regiones del array. Cuando se habilita, forcecopy provoca que el array acceder a las funciones de JNI para devolver copias con zonas rojas Un rojo zona es una región al final o al inicio del puntero devuelto que tiene un un valor especial que se verifica cuando se libera el array. Si los valores en la zona roja no coinciden con lo esperado, un búfer desbordado o subestimación. Esto provoca que se anule CheckJNI. Para habilitar modo forcecopy:
adb shell setprop dalvik.vm.jniopts forcecopy
Un ejemplo de error que CheckJNI debe detectar es escribir después del final de
un array obtenido de GetPrimitiveArrayCritical Esta operación
puede corromper el montón de Java. Si la escritura es
dentro de la zona roja CheckJNI, CheckJNI detecta el problema cuando
se llama al ReleasePrimitiveArrayCritical correspondiente. De lo contrario,
la escritura corrompe algún objeto aleatorio en
el montón de Java y puede provocar una falla de GC en el futuro. Si la memoria está dañada
es un campo de referencia, la GC puede detectar el error e imprimir el error Tried to
marcar <ptr> no se incluye en ningún espacio.
Este error ocurre cuando la GC intenta marcar un objeto que no puede encontrar un espacio. Después de que falla la verificación, la recolección de elementos no usados desvía las raíces e intenta comprueba si el objeto no válido es una raíz. Desde aquí, hay dos opciones: El objeto es una raíz o un objeto no raíz.
Ejemplo de raíz no válida
Si el objeto es una raíz no válida, se imprimen algunos
información útil:
art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:383] Tried to mark 0x2
not contained by any spaces
art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:384] Attempting see if it's a bad root art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:485] Found invalid root: 0x2 art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:486] Type=RootJavaFrame thread_id=1 location=Visiting method 'java.lang.Object com.google.gwt.collections.JavaReadableJsArray.get(int)' at dex PC 0x0002 (native PC 0xf19609d9) vreg=1
En este caso, vreg=1 dentro de
com.google.gwt.collections.JavaReadableJsArray.get es
que debería contener una referencia de montón, pero sí un puntero no válido
de la dirección 0x2. Esta raíz no es válida. Para
depurar este problema, usar oatdump en el archivo oat y observar
al método con la raíz no válida. En este caso, el error resultó
un error del compilador en el backend x86. Esta es la lista de cambios que lo solucionó: https://android-review.googlesource.com/#/c/133932/
Ejemplo de objeto dañado
Si el objeto no es una raíz, un resultado similar al siguiente copias:
01-15 12:38:00.196 1217 1238 E art : Attempting see if it's a bad root 01-15 12:38:00.196 1217 1238 F art : art/runtime/gc/collector/mark_sweep.cc:381] Can't mark invalid object
Cuando los daños en el montón no son una raíz no válida, es difícil depurarlos. Este mensaje de error indica que había al menos un objeto en el montón. que apuntaba al objeto no válido.