Auf dieser Seite wird beschrieben, wie Sie Korrektheits- und Leistungsprobleme bei der Garbage Collection (GC) der Android Runtime (ART) beheben können. Es erklärt, wie Sie GC-Verifizierungsoptionen verwenden, Lösungen für GC-Verifizierungsfehler finden und GC-Leistungsprobleme messen und beheben.
Informationen zum Arbeiten mit ART finden Sie auf den Seiten in diesem ART- und Dalvik- Abschnitt sowie im Dalvik Executable-Format . Weitere Hilfe zur Überprüfung des App-Verhaltens finden Sie unter Überprüfen des App-Verhaltens in der Android-Laufzeitumgebung (ART) .
ART GC-Übersicht
ART verfügt über einige verschiedene GC-Pläne, die darin bestehen, verschiedene Garbage Collectors auszuführen. Ab Android 8 (Oreo) ist der Standardplan Concurrent Copying (CC). Der andere GC-Plan ist Concurrent Mark Sweep (CMS).
Einige der Hauptmerkmale von Concurrent Copy GC sind:
- CC ermöglicht die Verwendung eines Bump-Pointer-Allokators namens RegionTLAB. Dadurch wird jedem App-Thread ein Thread-Local Allocation Buffer (TLAB) zugewiesen, der dann ohne Synchronisierung Objekte aus seinem TLAB zuweisen kann, indem er den „oberen“ Zeiger anstößt.
- CC führt eine Heap-Defragmentierung durch, indem Objekte gleichzeitig kopiert werden, ohne App-Threads anzuhalten. Dies wird mithilfe einer Lesebarriere erreicht, die Referenzlesevorgänge vom Heap abfängt, ohne dass der App-Entwickler eingreifen muss.
- GC hat nur eine kleine Pause, die im Hinblick auf die Heap-Größe zeitlich konstant ist.
- CC wird in Android 10 und höher zu einem generationsübergreifenden GC. Es ermöglicht das Sammeln junger Objekte, die oft recht schnell unerreichbar werden, mit geringem Aufwand. Dies hilft, indem es den GC-Durchsatz erhöht und die Notwendigkeit, eine Full-Heap-GC durchzuführen, erheblich verzögert.
Der andere GC, den ART noch unterstützt, ist CMS. Dieser GC unterstützt auch die Komprimierung, jedoch nicht gleichzeitig. Die Komprimierung wird vermieden, bis die App in den Hintergrund wechselt. Zu diesem Zeitpunkt werden die App-Threads angehalten, um die Komprimierung durchzuführen. Eine Komprimierung wird auch dann notwendig, wenn eine Objektzuweisung aufgrund von Fragmentierung fehlschlägt. In diesem Fall reagiert die App möglicherweise für einige Zeit nicht mehr.
Da CMS selten komprimiert und daher freie Objekte möglicherweise nicht zusammenhängend sind, verwendet es einen auf einer freien Liste basierenden Allokator namens RosAlloc. Im Vergleich zu RegionTLAB sind die Zuteilungskosten höher. Aufgrund der internen Fragmentierung kann die Speichernutzung für den Java-Heap bei CMS höher sein als bei CC.
GC-Verifizierungs- und Leistungsoptionen
Ändern Sie den GC-Typ
OEMs können den GC-Typ ändern. Der Änderungsprozess umfasst das Festlegen der Umgebungsvariablen ART_USE_READ_BARRIER
zur Erstellungszeit. Der Standardwert ist „true“, wodurch der CC-Collector aktiviert wird, da er die Lesebarriere verwendet. Für CMS sollte diese Variable explizit auf false gesetzt werden.
Standardmäßig wird der CC-Collector in Android 10 und höher im Generationsmodus ausgeführt. Um den Generationsmodus zu deaktivieren, kann das Befehlszeilenargument -Xgc:nogenerational_cc
verwendet werden. Alternativ kann die Systemeigenschaft wie folgt eingestellt werden:
adb shell setprop dalvik.vm.gctype nogenerational_ccDer CMS-Kollektor läuft immer im Generationsmodus.
Überprüfen Sie den Heap
Die Heap-Verifizierung ist wahrscheinlich die nützlichste GC-Option zum Debuggen von GC-bezogenen Fehlern oder Heap-Beschädigungen. Durch die Aktivierung der Heap-Überprüfung überprüft der GC an einigen Stellen während des Garbage-Collection-Prozesses die Richtigkeit des Heaps. Die Heap-Überprüfung verfügt über dieselben Optionen wie diejenigen, die den GC-Typ ändern. Wenn diese Option aktiviert ist, überprüft die Heap-Überprüfung die Wurzeln und stellt sicher, dass erreichbare Objekte nur auf andere erreichbare Objekte verweisen. Die GC-Verifizierung wird durch die Übergabe der folgenden -Xgc
Werte aktiviert:
- Wenn aktiviert, führt
[no]preverify
eine Heap-Verifizierung durch, bevor der GC gestartet wird. - Wenn aktiviert, führt
[no]presweepingverify
eine Heap-Überprüfung durch, bevor der Garbage Collector-Sweeping-Prozess gestartet wird. - Wenn diese Option aktiviert ist, führt
[no]postverify
eine Heap-Überprüfung durch, nachdem der GC das Durchsuchen abgeschlossen hat. -
[no]preverify_rosalloc
,[no]postsweepingverify_rosalloc
und[no]postverify_rosalloc
sind zusätzliche GC-Optionen, die nur den Status der internen Buchhaltung von RosAlloc überprüfen. Daher sind sie nur mit dem CMS-Kollektor anwendbar, der den RosAlloc-Allokator verwendet. Die wichtigsten überprüften Dinge sind, dass die magischen Werte mit den erwarteten Konstanten übereinstimmen und alle freien Speicherblöcke in der Kartefree_page_runs_
registriert sind.
Leistung
Es gibt zwei Haupttools zum Messen der GC-Leistung: GC-Timing-Dumps und Systrace. Es gibt auch eine erweiterte Version von Systrace namens Perfetto. Die visuelle Möglichkeit, GC-Leistungsprobleme zu messen, besteht darin, mit Systrace und Perfetto zu ermitteln, welche GCs lange Pausen verursachen oder App-Threads verhindern. Obwohl sich der ART GC im Laufe der Zeit erheblich verbessert hat, kann schlechtes Mutatorverhalten, wie beispielsweise eine übermäßige Zuweisung, immer noch zu Leistungsproblemen führen
Sammelstrategie
Der CC GC sammelt, indem er entweder einen jungen GC oder einen Full-Heap-GC ausführt. Idealerweise wird der junge GC häufiger durchgeführt. Der GC führt junge CC-Sammlungen durch, bis der Durchsatz (berechnet durch freigegebene Bytes/Sekunde GC-Dauer) des gerade abgeschlossenen Sammlungszyklus geringer ist als der mittlere Durchsatz von CC-Sammlungen mit vollem Heap. In diesem Fall wird anstelle des jungen CC der Full-Heap-CC für den nächsten gleichzeitigen GC ausgewählt. Nachdem die vollständige Heap-Sammlung abgeschlossen ist, wird der nächste GC wieder auf den jungen CC umgestellt. Ein Schlüsselfaktor, der dafür sorgt, dass diese Strategie funktioniert, ist, dass junges CC das Heap-Footprint-Limit nach Abschluss nicht anpasst. Dies führt dazu, dass junge CC immer häufiger auftreten, bis der Durchsatz geringer ist als bei Full-Heap-CC, was letztendlich dazu führt, dass der Heap wächst.
Verwenden Sie SIGQUIT, um Informationen zur GC-Leistung abzurufen
Um GC-Leistungszeiten für Apps zu erhalten, senden Sie SIGQUIT
an bereits laufende Apps oder übergeben Sie -XX:DumpGCPerformanceOnShutdown
an dalvikvm
, wenn Sie ein Befehlszeilenprogramm starten. Wenn eine App das ANR-Anforderungssignal ( SIGQUIT
) erhält, gibt sie Informationen zu ihren Sperren, Thread-Stacks und der GC-Leistung aus.
Um GC-Timing-Dumps zu erhalten, verwenden Sie:
adb shell kill -s QUIT PID
Dadurch wird eine Datei (mit Datum und Uhrzeit im Namen, z. B. anr_2020-07-13-19-23-39-817) in /data/anr/
erstellt. Diese Datei enthält einige ANR-Dumps sowie GC-Timings. Sie können die GC-Timings finden, indem Sie nach Dumping kumulativer Gc-Timings suchen. Diese Zeitangaben zeigen einige Dinge, die von Interesse sein könnten, einschließlich der Histogramminformationen für die Phasen und Pausen jedes GC-Typs. Die Pausen sind meist wichtiger anzusehen. Zum Beispiel:
young concurrent copying paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms
Dies zeigt, dass die durchschnittliche Pause 1,83 ms betrug, was niedrig genug sein sollte, dass es in den meisten Apps nicht zu fehlenden Frames kommt und kein Problem darstellen sollte.
Ein weiterer interessanter Bereich ist die Zeit zum Anhalten, die misst, wie lange es dauert, bis ein Thread einen Suspend-Punkt erreicht, nachdem der GC eine Suspendierung angefordert hat. Diese Zeit ist in den GC-Pausen enthalten. Daher ist es nützlich, festzustellen, ob lange Pausen dadurch verursacht werden, dass der GC langsam ist oder der Thread langsam anhält. Hier ist ein Beispiel für eine normale Zeit zum Anhalten auf einem Nexus 5:
suspend all histogram: Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us
Es gibt noch andere Bereiche von Interesse, einschließlich der Gesamtzeit und des GC-Durchsatzes. Beispiele:
Total time spent in GC: 502.251ms Mean GC size throughput: 92MB/s Mean GC object throughput: 1.54702e+06 objects/s
Hier ist ein Beispiel dafür, wie die GC-Timings einer bereits ausgeführten App ausgegeben werden:
adb shell kill -s QUIT PID
adb pull /data/anr/anr_2020-07-13-19-23-39-817
Zu diesem Zeitpunkt liegen die GC-Zeiten innerhalb von anr_2020-07-13-19-23-39-817
. Hier ist eine Beispielausgabe von 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
Tools zur Analyse von GC-Korrektheitsproblemen
Verschiedene Dinge können zu Abstürzen innerhalb von ART führen. Abstürze, die beim Lesen oder Schreiben in Objektfelder auftreten, können auf eine Beschädigung des Heapspeichers hinweisen. Wenn der GC während der Ausführung abstürzt, kann dies auch auf eine Heap-Beschädigung hinweisen. Die häufigste Ursache für Heap-Beschädigung ist falscher App-Code. Glücklicherweise gibt es Tools zum Debuggen von GC- und Heap-bezogenen Abstürzen, einschließlich der oben angegebenen Heap-Überprüfungsoptionen und CheckJNI.
Überprüfen Sie JNI
CheckJNI ist ein Modus, der JNI-Prüfungen hinzufügt, um das App-Verhalten zu überprüfen. Diese sind aus Leistungsgründen standardmäßig nicht aktiviert. Bei den Prüfungen werden einige Fehler erkannt, die zu einer Beschädigung des Heapspeichers führen können, beispielsweise die Verwendung ungültiger/veralteter lokaler und globaler Referenzen. So aktivieren Sie CheckJNI:
adb shell setprop dalvik.vm.checkjni true
Der Forcecopy-Modus von CheckJNI ist nützlich, um Schreibvorgänge über das Ende von Array-Regionen hinaus zu erkennen. Wenn Forcecopy aktiviert ist, bewirkt Forcecopy, dass die JNI-Funktionen für den Array-Zugriff Kopien mit roten Zonen zurückgeben. Eine rote Zone ist ein Bereich am Ende/Anfang des zurückgegebenen Zeigers, der einen speziellen Wert hat, der überprüft wird, wenn das Array freigegeben wird. Wenn die Werte im roten Bereich nicht den Erwartungen entsprechen, ist ein Pufferüberlauf oder -unterlauf aufgetreten. Dies führt zum Abbruch von CheckJNI. So aktivieren Sie den Forcecopy-Modus:
adb shell setprop dalvik.vm.jniopts forcecopy
Ein Beispiel für einen Fehler, den CheckJNI abfangen sollte, ist das Schreiben über das Ende eines von GetPrimitiveArrayCritical
erhaltenen Arrays hinaus. Dieser Vorgang kann den Java-Heap beschädigen. Wenn der Schreibvorgang innerhalb des roten Zonenbereichs von CheckJNI erfolgt, erkennt CheckJNI das Problem, wenn das entsprechende ReleasePrimitiveArrayCritical
aufgerufen wird. Andernfalls beschädigt der Schreibvorgang ein zufälliges Objekt im Java-Heap und kann einen zukünftigen GC-Absturz verursachen. Wenn es sich bei dem beschädigten Speicher um ein Referenzfeld handelt, fängt der GC möglicherweise den Fehler ab und gibt den Fehler aus . Versucht, <ptr> nicht in Leerzeichen enthalten zu markieren .
Dieser Fehler tritt auf, wenn der GC versucht, ein Objekt zu markieren, für das er keinen Platz findet. Nachdem diese Prüfung fehlschlägt, durchläuft der GC die Roots und versucht herauszufinden, ob das ungültige Objekt ein Root ist. Von hier aus gibt es zwei Möglichkeiten: Das Objekt ist ein Root- oder ein Nicht-Root-Objekt.
Ungültiges Root-Beispiel
Für den Fall, dass das Objekt ein ungültiger Stamm ist, werden einige nützliche Informationen ausgegeben: 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
In diesem Fall soll vreg=1
innerhalb von com.google.gwt.collections.JavaReadableJsArray.get
eine Heap-Referenz enthalten, enthält aber einen ungültigen Zeiger auf die Adresse 0x2
. Dies ist ein ungültiger Root. Um dieses Problem zu beheben, verwenden Sie oatdump
für die oat-Datei und sehen Sie sich die Methode mit dem ungültigen Root an. In diesem Fall stellte sich heraus, dass es sich bei dem Fehler um einen Compiler-Bug im x86-Backend handelte. Hier ist die Änderungsliste, mit der das Problem behoben wurde: https://android-review.googlesource.com/#/c/133932/
Beispiel für ein beschädigtes Objekt
Wenn das Objekt kein Stammobjekt ist, wird eine Ausgabe ähnlich der folgenden ausgegeben:
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
Wenn es sich bei der Heap-Beschädigung nicht um einen ungültigen Stamm handelt, ist das Debuggen schwierig. Diese Fehlermeldung weist darauf hin, dass sich mindestens ein Objekt im Heap befand, das auf das ungültige Objekt zeigte.