Men-debug pembersihan sampah memori ART

Halaman ini menjelaskan cara men-debug pembersihan sampah memori Android Runtime (ART) Masalah ketepatan dan performa (GC). Dokumen ini menjelaskan cara menggunakan verifikasi GC pilihan, mengidentifikasi solusi untuk kegagalan verifikasi GC, dan mengukur dan mengatasi masalah kinerja GC.

Untuk menggunakan ART, lihat halaman dalam ART dan Dalvik , dan format Dalvik Executable. Untuk bantuan tambahan dalam memverifikasi perilaku aplikasi, lihat Memverifikasi perilaku aplikasi pada Android Runtime (ART).

Ringkasan ART GC

ART memiliki beberapa rencana GC berbeda yang terdiri dari menjalankan proses sampah memori kolektor. Mulai dari Android 8 (Oreo), paket defaultnya adalah Penyalinan Serentak (CC). Paket GC lainnya adalah Concurrent Mark Sweep (CMS).

Beberapa karaktertik utama dari Concurrent Copy GC adalah:

• CC memungkinkan penggunaan alokator bump-pointer yang disebut RegionTLAB. Ini mengalokasikan thread-local alokasi buffer (TLAB) ke setiap thread aplikasi, yang kemudian dapat mengalokasikan objek dari TLAB-nya dengan menggeser "bagian atas" tanpa sinkronisasi apa pun.
• CC melakukan defragmentasi heap dengan menyalin objek secara serentak tanpa menjeda thread aplikasi. Hal ini dilakukan dengan bantuan read-barrier yang mencegat pembacaan referensi dari heap, tanpa perlu intervensi apa pun dari developer aplikasi.
• GC hanya memiliki satu jeda kecil, yang konstan dalam kaitannya dengan ukuran heap.
• CC mencakup GC generasi di Android 10 dan yang lebih tinggi. Hal ini memungkinkan pengumpulan muda, yang sering kali tidak dapat dijangkau dengan cukup cepat, dengan sedikit usaha. Hal ini membantu dengan meningkatkan throughput GC dan sangat menunda kebutuhan untuk melakukan GC heap penuh.

GC lain yang masih didukung ART adalah CMS. Ini GC juga mendukung pemadatan, tetapi tidak secara serentak. Pemadatan dihindari hingga aplikasi ke latar belakang, pada saat thread aplikasi dijeda untuk melakukan pemadatan. Pemadatan juga diperlukan jika alokasi objek gagal karena fragmentasi. Di sini aplikasi mungkin berpotensi menjadi tidak responsif untuk beberapa waktu.

Karena CMS jarang memadatkan, dan dengan demikian objek bebas mungkin tidak berdekatan, CMS menggunakan pengalokasi berbasis daftar bebas yang disebut RosAlloc. Memiliki biaya alokasi yang lebih tinggi dibandingkan ke RegionTLAB. Terakhir, karena fragmentasi internal, penggunaan memori untuk heap Java bisa lebih tinggi untuk CMS daripada CC.

Opsi verifikasi dan performa GC

Mengubah jenis GC

OEM dapat mengubah jenis GC. Proses perubahan melibatkan penetapan variabel lingkungan ART_USE_READ_BARRIER pada waktu build. Nilai defaultnya adalah true (benar), yang mengaktifkan kolektor CC karena menggunakan barrier baca. Untuk CMS, variabel harus secara eksplisit ditetapkan ke salah.

Secara default, kolektor CC berjalan dalam mode generasi di Android 10 dan yang lebih tinggi. Kepada menonaktifkan mode generasi, argumen command line -Xgc:nogenerational_cc dapat data Atau, properti sistem dapat ditetapkan sebagai berikut:

adb shell setprop dalvik.vm.gctype nogenerational_cc

Kolektor CMS selalu berjalan dalam mode generasi.

Memverifikasi heap

Verifikasi heap mungkin merupakan opsi GC yang paling berguna untuk proses debug Kesalahan terkait GC atau kerusakan heap. Mengaktifkan verifikasi heap menyebabkan GC untuk memeriksa ketepatan heap di beberapa titik selama pembersihan sampah memori proses pengumpulan data. Verifikasi heap memiliki opsi yang sama dengan yang mengubah tipe GC. Jika diaktifkan, verifikasi heap akan memverifikasi akar dan memastikan bahwa objek yang dapat dijangkau hanya mereferensikan objek lain yang dapat dijangkau. JG verifikasi diaktifkan dengan meneruskan nilai -Xgc berikut:

• Jika diaktifkan, [no]preverify akan melakukan verifikasi heap sebelum memulai GC.
• Jika diaktifkan, [no]presweepingverify akan melakukan verifikasi heap sebelum memulai proses pembersihan pembersihan sampah memori.
• Jika diaktifkan, [no]postverify akan melakukan verifikasi heap setelah GC selesai digeser.
• [no]preverify_rosalloc, [no]postsweepingverify_rosalloc, dan [no]postverify_rosalloc adalah opsi GC tambahan yang memverifikasi hanya status akuntansi internal RosAlloc. Oleh karena itu, aturan tersebut hanya berlaku untuk kolektor CMS, yang menggunakan RosAlloc {i>alokator<i}. Hal utama yang diverifikasi adalah nilai-nilai ajaib itu cocok dengan konstanta yang diharapkan, dan blok memori bebas semuanya terdaftar di peta free_page_runs_.

Performa

Ada dua alat utama untuk mengukur kinerja GC, pengaturan waktu GC dump dan Systrace. Ada juga versi lanjutan Systrace yang disebut Perfetto. Cara visual untuk mengukur masalah performa GC adalah menggunakan Systrace dan Perfetto untuk menentukan GC mana yang menyebabkan jeda lama atau melakukan preemption terhadap thread aplikasi. Meskipun ART GC telah meningkat secara signifikan dari waktu ke waktu, mutator yang buruk perilaku data, seperti alokasi berlebihan, masih dapat menyebabkan masalah performa

Strategi pengumpulan

CC GC yang dikumpulkan dengan menjalankan GC muda atau GC full-heap. Idealnya, GC muda yang dijalankan lebih sering. GC melakukan pengumpulan CC muda hingga throughput (dihitung berdasarkan byte yang dibebaskan/detik dari durasi GC) dari siklus pengumpulan yang baru saja selesai kurang dari throughput rata-rata koleksi CC heap penuh. Jika ini terjadi, CC heap penuh dipilih untuk GC serentak alih-alih CC muda. Setelah pengumpulan penuh heap selesai, langkah berikutnya GC dialihkan kembali ke CC muda. Salah satu faktor utama yang membuat strategi ini berhasil adalah CC muda tidak menyesuaikan batas jejak heap setelah selesai. Hal ini menyebabkan CC muda lebih sering dan lebih sering sampai throughput lebih rendah daripada CC full-heap, yang pada akhirnya meningkatkan heap.

Menggunakan SIGQUIT untuk mendapatkan info performa GC

Untuk mendapatkan pengaturan waktu performa GC untuk aplikasi, kirim SIGQUIT ke sudah menjalankan aplikasi atau meneruskan -XX:DumpGCPerformanceOnShutdown ke dalvikvm saat memulai program command line. Saat aplikasi menjadi sinyal permintaan ANR (SIGQUIT), ia membuang informasi yang terkait dengan kuncinya, thread stack, dan performa GC.

Untuk mendapatkan dump pengaturan waktu GC, gunakan:

adb shell kill -s QUIT PID

Ini membuat file (dengan tanggal dan waktu dalam nama seperti anr_2020-07-13-19-23-39-817) di /data/anr/. Ini berisi beberapa dump ANR serta pengaturan waktu GC. Anda dapat menemukan Pengaturan waktu GC dengan menelusuri Pembuangan pengaturan waktu Gc kumulatif. Waktu ini menunjukkan beberapa hal yang mungkin menarik, termasuk info histogram untuk setiap fase dan jeda jenis GC. Jeda biasanya lebih penting untuk diperhatikan di. Contoh:

young concurrent copying paused:	Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms

Hal ini menunjukkan bahwa jeda rata-rata adalah 1,83 md, yang seharusnya cukup rendah sehingga itu tidak menyebabkan {i>frame<i} yang terlewat di sebagian besar aplikasi dan seharusnya tidak menjadi masalah.

Area menarik lainnya adalah waktu untuk menangguhkan, yang mengukur berapa lama waktu yang dibutuhkan thread untuk mencapai titik penangguhan setelah GC meminta dan ditangguhkan. Waktu ini termasuk dalam penjedaan GC, jadi berguna untuk menentukan apakah jeda lama disebabkan oleh GC yang lambat atau thread menangguhkan secara perlahan. Berikut ini contoh waktu normal untuk menangguhkan di Nexus 5:

suspend all histogram:	Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us

Ada area minat lain, termasuk total waktu yang dihabiskan dan GC yang konsisten. Contoh:

Total time spent in GC: 502.251ms
Mean GC size throughput: 92MB/s
Mean GC object throughput: 1.54702e+06 objects/s

Berikut adalah contoh cara membuang pengaturan waktu GC dari aplikasi yang sudah berjalan:

adb shell kill -s QUIT PID
adb pull /data/anr/anr_2020-07-13-19-23-39-817

Pada tahap ini, pengaturan waktu GC berada di dalam anr_2020-07-13-19-23-39-817. Berikut adalah contoh output dari 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

Alat untuk menganalisis soal ketepatan GC

Berbagai hal dapat menyebabkan error di dalam ART. Error yang terjadi pembacaan atau penulisan ke bidang objek dapat mengindikasikan korupsi heap. Jika GC mengalami error saat dijalankan, tetapi juga dapat menunjukkan kerusakan heap. Penyebab paling umum kerusakan heap adalah kode aplikasi yang salah. Untungnya, ada alat untuk GC debug dan error terkait heap, termasuk opsi verifikasi heap yang ditentukan di atas, dan CheckJNI.

CheckJNI

CheckJNI adalah mode yang menambahkan pemeriksaan JNI untuk memverifikasi perilaku aplikasi; permintaan ini tidak diaktifkan oleh default untuk alasan performa. Pemeriksaan ini mendeteksi beberapa {i>error<i} yang dapat menyebabkan kerusakan heap, seperti penggunaan referensi lokal dan global yang tidak valid/usang. Untuk mengaktifkan CheckJNI:

adb shell setprop dalvik.vm.checkjni true

Mode forcecopy CheckJNI berguna untuk mendeteksi menulis melewati akhir region array. Jika diaktifkan, paksa salinan akan menyebabkan array mengakses fungsi JNI untuk menampilkan salinan dengan zona merah. merah zona adalah region di akhir/awal pointer yang ditampilkan yang memiliki nilai khusus, yang diverifikasi saat himpunan dirilis. Jika nilai pada zona merah tidak sesuai dengan yang diharapkan, {i>buffer overrun<i} atau underrun terjadi. Ini menyebabkan CheckJNI dibatalkan. Untuk mengaktifkan mode forcecopy:

adb shell setprop dalvik.vm.jniopts forcecopy

Contoh {i>error<i} yang harus ditangkap CheckJNI adalah menulis melewati akhir array yang diperoleh dari GetPrimitiveArrayCritical. Operasi ini bisa merusak heap Java. Jika penulisannya adalah di dalam area zona merah CheckJNI, kemudian CheckJNI menangkap masalah saat ReleasePrimitiveArrayCritical yang sesuai dipanggil. Jika tidak, penulisannya merusak beberapa objek acak di heap Java dan bisa menyebabkan kecelakaan GC di masa mendatang. Jika memori rusak adalah isian referensi, maka GC dapat menangkap {i>error<i} dan mencetak {i>error<i} Dicoba tanda <ptr> tidak terdapat dalam spasi mana pun.

Kesalahan ini terjadi ketika GC mencoba menandai objek yang tidak dapat cari tempat yang cocok. Setelah pemeriksaan ini gagal, GC menelusuri {i>root<i} dan mencoba untuk melihat apakah objek yang tidak valid adalah {i>root<i}. Selanjutnya, ada dua opsi: Objek adalah root atau objek nonroot.

Contoh root tidak valid

Dalam kasus di mana objek merupakan {i>root<i} yang tidak valid, objek tersebut akan mencetak beberapa informasi berguna: 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

Dalam hal ini, vreg=1 di dalam com.google.gwt.collections.JavaReadableJsArray.get sama dengan seharusnya berisi referensi heap, tetapi berisi pointer yang tidak valid dari alamat 0x2. Ini adalah akar yang tidak valid. Kepada debug masalah ini, gunakan oatdump pada file oat dan lihat metode dengan {i>root<i} yang tidak valid. Dalam hal ini, kesalahan ternyata menjadi {i>bug<i} kompilator di backend x86. Berikut daftar perubahan yang telah memperbaikinya: https://android-review.googlesource.com/#/c/133932/

Contoh objek yang rusak

Jika objek bukan root, output yang mirip dengan berikut ini cetakan foto:

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

Jika kerusakan heap bukan root yang tidak valid, sulit untuk di-debug. Pesan error ini menunjukkan bahwa setidaknya ada satu objek dalam heap yang mengarah ke objek yang tidak valid.