Halaman ini menjelaskan cara men-debug kebenaran dan masalah kinerja pengumpulan sampah (GC) Android Runtime (ART). Panduan ini menjelaskan cara menggunakan opsi verifikasi GC, mengidentifikasi solusi untuk kegagalan verifikasi GC, dan mengukur serta mengatasi masalah kinerja GC.
Untuk bekerja dengan ART, lihat halaman di bagian ART dan Dalvik ini, dan format Dalvik Executable . Untuk bantuan tambahan dalam memverifikasi perilaku aplikasi, lihat Memverifikasi perilaku aplikasi pada runtime Android (ART) .
Ikhtisar ART GC
ART memiliki beberapa rencana GC berbeda yang terdiri dari menjalankan pengumpul sampah yang berbeda. Dimulai dengan Android 8 (Oreo), paket defaultnya adalah Concurrent Copying (CC). Paket GC lainnya adalah Concurrent Mark Sweep (CMS).
Beberapa karakteristik utama dari Concurrent Copying GC adalah:
- CC memungkinkan penggunaan pengalokasi bump-pointer yang disebut RegionTLAB. Ini mengalokasikan buffer alokasi thread-lokal (TLAB) ke setiap thread aplikasi, yang kemudian dapat mengalokasikan objek dari TLAB-nya dengan menekan penunjuk "atas", tanpa sinkronisasi apa pun.
- CC melakukan defragmentasi heap dengan menyalin objek secara bersamaan tanpa menjeda thread aplikasi. Hal ini dicapai dengan bantuan penghalang baca yang mencegat pembacaan referensi dari heap, tanpa memerlukan intervensi apa pun dari pengembang aplikasi.
- GC hanya memiliki satu jeda kecil, yang konstan seiring dengan ukuran heap.
- CC meluas menjadi GC generasi di Android 10 dan lebih tinggi. Hal ini memungkinkan pengumpulan objek-objek muda, yang seringkali 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. GC ini juga mendukung pemadatan, tetapi tidak secara bersamaan. Pemadatan dihindari hingga aplikasi masuk ke latar belakang, yang pada saat itu thread aplikasi dijeda untuk melakukan pemadatan. Pemadatan juga diperlukan ketika alokasi objek gagal karena fragmentasi. Dalam hal ini, aplikasi berpotensi menjadi tidak responsif selama beberapa waktu.
Karena CMS jarang dipadatkan, sehingga objek bebas mungkin tidak bersebelahan, CMS menggunakan pengalokasi berbasis daftar bebas yang disebut RosAlloc. Ini memiliki biaya alokasi yang lebih tinggi dibandingkan dengan RegionTLAB. Terakhir, karena fragmentasi internal, penggunaan memori untuk heap Java bisa lebih tinggi untuk CMS dibandingkan CC.
Verifikasi GC dan opsi kinerja
Ubah tipe GC
OEM dapat mengubah tipe GC. Proses perubahan melibatkan pengaturan variabel lingkungan ART_USE_READ_BARRIER
pada waktu pembuatan. Nilai defaultnya adalah true, yang mengaktifkan kolektor CC karena menggunakan penghalang baca. Untuk CMS, variabel ini harus secara eksplisit disetel ke false.
Secara default, kolektor CC berjalan dalam mode generasi di Android 10 dan lebih tinggi. Untuk menonaktifkan mode generasi, argumen baris perintah -Xgc:nogenerational_cc
dapat digunakan. Alternatifnya, properti sistem dapat diatur sebagai berikut:
adb shell setprop dalvik.vm.gctype nogenerational_ccKolektor CMS selalu berjalan dalam mode generasi.
Verifikasi tumpukannya
Verifikasi heap mungkin merupakan opsi GC yang paling berguna untuk men-debug error terkait GC atau kerusakan heap. Mengaktifkan verifikasi heap menyebabkan GC memeriksa kebenaran heap di beberapa titik selama proses pengumpulan sampah. Verifikasi heap memiliki opsi yang sama dengan opsi yang mengubah jenis GC. Jika diaktifkan, verifikasi heap memverifikasi akar dan memastikan bahwa objek yang dapat dijangkau hanya mereferensikan objek lain yang dapat dijangkau. Verifikasi GC diaktifkan dengan meneruskan nilai -Xgc
berikut:
- Jika diaktifkan,
[no]preverify
melakukan verifikasi heap sebelum memulai GC. - Jika diaktifkan,
[no]presweepingverify
melakukan verifikasi tumpukan sebelum memulai proses pembersihan pengumpul sampah. - Jika diaktifkan,
[no]postverify
melakukan verifikasi tumpukan setelah GC selesai menyapu. -
[no]preverify_rosalloc
,[no]postsweepingverify_rosalloc
, dan[no]postverify_rosalloc
adalah opsi GC tambahan yang hanya memverifikasi status akuntansi internal RosAlloc. Oleh karena itu, ini hanya berlaku dengan kolektor CMS, yang menggunakan pengalokasi RosAlloc. Hal utama yang diverifikasi adalah bahwa nilai ajaib cocok dengan konstanta yang diharapkan, dan blok memori bebas semuanya terdaftar di petafree_page_runs_
.
Pertunjukan
Ada dua alat utama untuk mengukur kinerja GC, GC timing dumps dan Systrace. Ada juga versi lanjutan dari Systrace, yang disebut Perfetto. Cara visual untuk mengukur masalah performa GC adalah dengan menggunakan Systrace dan Perfetto untuk menentukan GC mana yang menyebabkan jeda panjang atau mendahului thread aplikasi. Meskipun ART GC telah meningkat secara signifikan dari waktu ke waktu, perilaku mutator yang buruk, seperti alokasi yang berlebihan, masih dapat menyebabkan masalah kinerja
Strategi pengumpulan
CC GC mengumpulkan dengan menjalankan GC muda atau GC heap penuh. Idealnya GC muda lebih sering dijalankan. GC melakukan pengumpulan CC muda hingga throughput (dihitung berdasarkan byte yang dibebaskan/detik durasi GC) dari siklus pengumpulan yang baru saja selesai kurang dari rata-rata throughput pengumpulan CC full-heap. Jika hal ini terjadi, CC tumpukan penuh dipilih untuk GC bersamaan berikutnya, bukan CC muda. Setelah pengumpulan heap penuh selesai, GC berikutnya dialihkan kembali ke CC muda. Salah satu faktor kunci yang membuat strategi ini berhasil adalah CC muda tidak menyesuaikan batas tumpukan heap setelah selesai. Hal ini menyebabkan CC muda terjadi lebih sering hingga throughputnya lebih rendah daripada CC full-heap, yang pada akhirnya menambah heap.
Gunakan SIGQUIT untuk mendapatkan info kinerja GC
Untuk mendapatkan pengaturan waktu kinerja GC untuk aplikasi, kirim SIGQUIT
ke aplikasi yang sudah berjalan atau teruskan -XX:DumpGCPerformanceOnShutdown
ke dalvikvm
saat memulai program baris perintah. Saat aplikasi mendapat sinyal permintaan ANR ( SIGQUIT
), aplikasi membuang informasi terkait kunci, tumpukan thread, dan performa GC.
Untuk mendapatkan dump 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/
. File ini berisi beberapa dump ANR serta pengaturan waktu GC. Anda dapat menemukan timing GC dengan mencari Timing Gc kumulatif Dumping . Pengaturan waktu ini menunjukkan beberapa hal yang mungkin menarik, termasuk informasi histogram untuk setiap fase dan jeda jenis GC. Jeda biasanya lebih penting untuk diperhatikan. Misalnya:
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 ms, yang seharusnya cukup rendah sehingga tidak menyebabkan frame terlewat di sebagian besar aplikasi dan tidak perlu menjadi perhatian.
Area menarik lainnya adalah waktu untuk menangguhkan, yang mengukur berapa lama waktu yang dibutuhkan sebuah thread untuk mencapai titik penangguhan setelah GC meminta agar thread tersebut melakukan penangguhan. Waktu ini termasuk dalam jeda GC, jadi berguna untuk menentukan apakah jeda panjang disebabkan oleh lambatnya GC atau thread ditangguhkan dengan lambat. Berikut ini contoh waktu normal untuk melakukan suspend pada Nexus 5:
suspend all histogram: Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us
Ada bidang lain yang menarik, termasuk total waktu yang dihabiskan dan throughput GC. Contoh:
Total time spent in GC: 502.251ms Mean GC size throughput: 92MB/s Mean GC object throughput: 1.54702e+06 objects/s
Berikut ini 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 titik ini pengaturan waktu GC ada di dalam anr_2020-07-13-19-23-39-817
. Berikut contoh keluaran 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 masalah kebenaran GC
Berbagai hal dapat menyebabkan crash di dalam ART. Gangguan yang terjadi saat membaca atau menulis pada bidang objek mungkin mengindikasikan kerusakan tumpukan. Jika GC mengalami error saat dijalankan, hal ini juga dapat menunjukkan adanya tumpukan korupsi. Penyebab paling umum dari kerusakan heap adalah kode aplikasi yang salah. Untungnya, ada alat untuk men-debug GC dan kerusakan terkait heap, termasuk opsi verifikasi heap yang ditentukan di atas, dan CheckJNI.
PeriksaJNI
CheckJNI adalah mode yang menambahkan pemeriksaan JNI untuk memverifikasi perilaku aplikasi; ini tidak diaktifkan secara default karena alasan kinerja. Pemeriksaan menemukan beberapa kesalahan yang dapat menyebabkan kerusakan tumpukan, seperti penggunaan referensi lokal dan global yang tidak valid/basi. Untuk mengaktifkan CheckJNI:
adb shell setprop dalvik.vm.checkjni true
Mode forcecopy CheckJNI berguna untuk mendeteksi penulisan yang melewati akhir wilayah array. Saat diaktifkan, forcecopy menyebabkan fungsi JNI akses array mengembalikan salinan dengan zona merah. Zona merah adalah wilayah di akhir/awal penunjuk yang dikembalikan yang memiliki nilai khusus, yang diverifikasi saat larik dilepaskan. Jika nilai di zona merah tidak sesuai dengan yang diharapkan, terjadi buffer overrun atau underrun. Hal ini menyebabkan CheckJNI dibatalkan. Untuk mengaktifkan mode penyalinan paksa:
adb shell setprop dalvik.vm.jniopts forcecopy
Contoh kesalahan yang harus ditangkap oleh CheckJNI adalah menulis melewati akhir array yang diperoleh dari GetPrimitiveArrayCritical
. Operasi ini dapat merusak tumpukan Java. Jika penulisan berada dalam area zona merah CheckJNI, maka CheckJNI menangkap masalah tersebut ketika ReleasePrimitiveArrayCritical
yang sesuai dipanggil. Jika tidak, penulisan akan merusak beberapa objek acak di heap Java dan dapat menyebabkan error GC di masa mendatang. Jika memori yang rusak adalah bidang referensi, maka GC dapat menangkap kesalahan tersebut dan mencetak kesalahan tersebut Mencoba menandai <ptr> tidak terkandung oleh spasi apa pun .
Kesalahan ini terjadi ketika GC mencoba menandai objek yang tidak dapat menemukan ruangnya. Setelah pemeriksaan ini gagal, GC menelusuri akar dan mencoba melihat apakah objek yang tidak valid adalah akar. Dari sini, ada dua pilihan: Objeknya adalah objek root atau objek nonroot.
Contoh root tidak valid
Dalam kasus di mana objek adalah akar yang tidak valid, ia 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
seharusnya berisi referensi heap, tetapi berisi penunjuk alamat 0x2
yang tidak valid. Ini adalah root yang tidak valid. Untuk men-debug masalah ini, gunakan oatdump
pada file oat dan lihat metode dengan root yang tidak valid. Dalam kasus ini, kesalahan tersebut ternyata merupakan bug kompiler di backend x86. Berikut daftar perubahan yang memperbaikinya: https://android-review.googlesource.com/#/c/133932/
Contoh objek yang rusak
Jika objeknya bukan root, hasilnya mirip dengan cetakan berikut:
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 merupakan root yang tidak valid, maka akan sulit untuk melakukan debug. Pesan kesalahan ini menunjukkan bahwa setidaknya ada satu objek di heap yang menunjuk ke objek yang tidak valid.