ART çöp toplama işleminde hata ayıklama

Bu sayfada Android Çalışma Zamanı (ART) çöp toplama (GC) doğruluğu ve performans sorunlarının nasıl ayıklanacağı açıklanmaktadır. GC doğrulama seçeneklerinin nasıl kullanılacağını, GC doğrulama hatalarına yönelik çözümlerin nasıl belirleneceğini ve GC performans sorunlarının nasıl ölçüleceğini ve ele alınacağını açıklar.

ART ile çalışmak için bu ART ve Dalvik bölümündeki sayfalara ve Dalvik Çalıştırılabilir formatına bakın. Uygulama davranışını doğrulama konusunda ek yardım için bkz. Android çalışma zamanında (ART) uygulama davranışını doğrulama .

ART GC'ye genel bakış

ART'ın farklı çöp toplayıcıları çalıştırmayı içeren birkaç farklı GC planı vardır. Android 8'den (Oreo) itibaren varsayılan plan Eşzamanlı Kopyalama'dır (CC). Diğer GC planı Eşzamanlı İşaretleme Süpürme'dir (CMS).

Eşzamanlı Kopyalama GC'nin ana özelliklerinden bazıları şunlardır:

• CC, RegionTLAB adı verilen bir çarpma işaretçisi ayırıcısının kullanılmasına olanak sağlar. Bu, her uygulama iş parçacığına bir iş parçacığı yerel tahsis arabelleği (TLAB) tahsis eder; bu, daha sonra herhangi bir senkronizasyon olmadan "üst" işaretçiyi çarparak nesneleri TLAB'sinden ayırabilir.
• CC, uygulama iş parçacıklarını duraklatmadan nesneleri eşzamanlı olarak kopyalayarak yığın birleştirme işlemini gerçekleştirir. Bu, uygulama geliştiricisinin herhangi bir müdahalesine gerek kalmadan yığından referans okumalarını engelleyen bir okuma bariyeri yardımıyla gerçekleştirilir.
• GC'de yalnızca yığın boyutuna bağlı olarak zaman içinde sabit olan küçük bir duraklama vardır.
• CC, Android 10 ve sonraki sürümlerde nesiller boyu bir GC olacak şekilde genişliyor. Genellikle oldukça hızlı bir şekilde ulaşılamayan genç nesnelerin çok az çabayla toplanmasına olanak sağlar. Bu, GC verimini artırarak ve tam yığın GC gerçekleştirme ihtiyacını önemli ölçüde geciktirerek yardımcı olur.

ART'ın hala desteklediği diğer GC ise CMS'dir. Bu GC aynı zamanda sıkıştırmayı da destekler ancak aynı anda desteklemez. Uygulama arka plana geçene kadar sıkıştırmadan kaçınılır; bu sırada uygulama iş parçacıkları sıkıştırma gerçekleştirmek üzere duraklatılır. Parçalanma nedeniyle nesne tahsisi başarısız olduğunda sıkıştırma da gerekli olur. Bu durumda uygulama potansiyel olarak bir süre yanıt vermeyebilir.

CMS nadiren sıkıştırıldığından ve dolayısıyla serbest nesneler bitişik olamayabileceğinden, RosAlloc adı verilen serbest liste tabanlı bir ayırıcıyı kullanır. RegionTLAB ile karşılaştırıldığında daha yüksek bir tahsis maliyetine sahiptir. Son olarak, dahili parçalanma nedeniyle Java yığınının bellek kullanımı CMS için CC'den daha yüksek olabilir.

GC doğrulama ve performans seçenekleri

GC türünü değiştirin

OEM'ler GC tipini değiştirebilir. Değişiklik süreci, oluşturma sırasında ART_USE_READ_BARRIER ortam değişkeninin ayarlanmasını içerir. Varsayılan değer true olup CC toplayıcının okuma bariyerini kullanmasına olanak sağlar. CMS için bu değişken açıkça false olarak ayarlanmalıdır.

CC toplayıcı, varsayılan olarak Android 10 ve sonraki sürümlerde nesil modunda çalışır. Nesil modunu devre dışı bırakmak için -Xgc:nogenerational_cc komut satırı argümanı kullanılabilir. Alternatif olarak sistem özelliği şu şekilde ayarlanabilir:

adb shell setprop dalvik.vm.gctype nogenerational_cc

CMS toplayıcı her zaman nesil modunda çalışır.

Yığın doğrulama

Yığın doğrulaması muhtemelen GC ile ilgili hataların veya yığın bozulmasının hatalarını ayıklamak için en kullanışlı GC seçeneğidir. Yığın doğrulamanın etkinleştirilmesi, GC'nin çöp toplama işlemi sırasında yığının doğruluğunu birkaç noktada kontrol etmesine neden olur. Yığın doğrulaması, GC türünü değiştirenlerle aynı seçenekleri paylaşır. Etkinleştirilirse, yığın doğrulaması kökleri doğrular ve ulaşılabilir nesnelerin yalnızca diğer erişilebilir nesnelere referans vermesini sağlar. GC doğrulaması, aşağıdaki -Xgc değerlerinin iletilmesiyle etkinleştirilir:

• Etkinleştirilirse, [no]preverify GC'yi başlatmadan önce yığın doğrulaması gerçekleştirir.
• Etkinleştirilirse, [no]presweepingverify çöp toplayıcı süpürme işlemine başlamadan önce yığın doğrulaması gerçekleştirir.
• Etkinleştirilirse, [no]postverify GC süpürmeyi bitirdikten sonra yığın doğrulaması gerçekleştirir.
• [no]preverify_rosalloc , [no]postsweepingverify_rosalloc ve [no]postverify_rosalloc yalnızca RosAlloc'un dahili muhasebesinin durumunu doğrulayan ek GC seçenekleridir. Bu nedenle bunlar yalnızca RosAlloc ayırıcıyı kullanan CMS toplayıcıyla uygulanabilir. Doğrulanan başlıca şeyler, sihirli değerlerin beklenen sabitlerle eşleştiği ve boş bellek bloklarının tamamının free_page_runs_ haritasına kayıtlı olduğudur.

Verim

GC performansını ölçmek için iki ana araç vardır: GC zamanlama dökümleri ve Systrace. Ayrıca Systrace'in Perfetto adı verilen gelişmiş bir sürümü de vardır. GC performans sorunlarını ölçmenin görsel yolu, hangi GC'lerin uzun duraklamalara veya uygulama iş parçacıklarını engellemeye neden olduğunu belirlemek için Systrace ve Perfetto'yu kullanmaktır. ART GC zamanla önemli ölçüde gelişmiş olsa da aşırı tahsis gibi kötü değiştirici davranışlar hâlâ performans sorunlarına neden olabilir

Toplama stratejisi

CC GC, genç bir GC veya tam yığın GC çalıştırarak toplanır. İdeal olarak genç GC daha sık çalıştırılır. GC, henüz tamamlanan toplama döngüsünün verimi (serbest bırakılan bayt/GC süresinin saniyesi olarak hesaplanan) tam yığın CC koleksiyonlarının ortalama veriminden daha az olana kadar genç CC koleksiyonları yapar. Bu meydana geldiğinde, genç CC yerine bir sonraki eşzamanlı GC için tam yığın CC seçilir. Tam yığın toplama tamamlandıktan sonra sonraki GC, genç CC'ye geri döner. Bu stratejinin işe yaramasını sağlayan önemli faktörlerden biri, genç CC'nin, tamamlandıktan sonra yığın ayak izi sınırını ayarlamamasıdır. Bu, iş hacmi tam yığın CC'den daha düşük olana kadar genç CC'nin giderek daha sık gerçekleşmesine neden olur, bu da yığının büyümesiyle sonuçlanır.

GC performans bilgilerini almak için SIGQUIT'i kullanın

Uygulamalara ilişkin GC performans zamanlamalarını almak için, halihazırda çalışmakta olan uygulamalara SIGQUIT gönderin veya bir komut satırı programını başlatırken dalvikvm -XX:DumpGCPerformanceOnShutdown komutunu iletin. Bir uygulama ANR istek sinyalini ( SIGQUIT ) aldığında kilitleri, iş parçacığı yığınları ve GC performansıyla ilgili bilgileri döker.

GC zamanlama dökümlerini almak için şunu kullanın:

adb shell kill -s QUIT PID

Bu, /data/anr/ içinde bir dosya (anr_2020-07-13-19-23-39-817 gibi adında tarih ve saat bulunan) oluşturur. Bu dosya, bazı ANR dökümlerinin yanı sıra GC zamanlamalarını da içerir. GC zamanlamalarını , Boşaltma kümülatif Gc zamanlamalarını arayarak bulabilirsiniz. Bu zamanlamalar, her bir GC türünün aşamaları ve duraklamaları için histogram bilgileri de dahil olmak üzere ilgi çekici olabilecek birkaç şeyi gösterir. Duraklamalara bakmak genellikle daha önemlidir. Örneğin:

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

Bu, ortalama duraklamanın 1,83 ms olduğunu gösteriyor; bu, çoğu uygulamada karelerin kaçırılmasına neden olmayacak kadar düşük olmalı ve endişe yaratmamalıdır.

Bir başka ilgi alanı da askıya alma süresidir; bu, GC'nin askıya alınmasını talep etmesinden sonra bir iş parçacığının askıya alma noktasına ulaşmasının ne kadar sürdüğünü ölçer. Bu süre GC duraklamalarına dahildir, bu nedenle uzun duraklamaların GC'nin yavaş olmasından mı yoksa iş parçacığının yavaşça askıya alınmasından mı kaynaklandığını belirlemek yararlı olur. Nexus 5'te askıya alınacak normal süreye bir örnek:

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

Harcanan toplam süre ve GC verimi dahil olmak üzere başka ilgi alanları da vardır. Örnekler:

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

Zaten çalışmakta olan bir uygulamanın GC zamanlamalarının nasıl boşaltılacağına dair bir örnek:

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

Bu noktada GC zamanlamaları anr_2020-07-13-19-23-39-817 içindedir. İşte Google Haritalar'dan örnek çıktı:

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

GC doğruluğu problemlerini analiz etmek için araçlar

ART'ın içinde çeşitli şeyler çökmelere neden olabilir. Nesne alanlarına okuma veya yazma sırasında meydana gelen çökmeler yığın bozulmasına işaret edebilir. GC çalışırken çökerse, bu aynı zamanda yığın bozulmasına da işaret edebilir. Yığın bozulmasının en yaygın nedeni yanlış uygulama kodudur. Neyse ki, yukarıda belirtilen yığın doğrulama seçenekleri ve CheckJNI dahil olmak üzere GC ve yığınla ilgili çökmelerde hata ayıklamak için araçlar vardır.

JNI'yi kontrol edin

CheckJNI, uygulama davranışını doğrulamak için JNI kontrolleri ekleyen bir moddur; bunlar performans nedeniyle varsayılan olarak etkin değildir. Denetimler, geçersiz/eski yerel ve genel referansların kullanılması gibi yığın bozulmasına neden olabilecek birkaç hatayı yakalar. CheckJNI'yi etkinleştirmek için:

adb shell setprop dalvik.vm.checkjni true

CheckJNI'nin zorla kopyalama modu, dizi bölgelerinin sonundan sonraki yazma işlemlerini tespit etmek için kullanışlıdır. Etkinleştirildiğinde, zorla kopyalama, dizi erişimi JNI işlevlerinin kırmızı bölgelere sahip kopyalar döndürmesine neden olur. Kırmızı bölge, döndürülen işaretçinin sonunda/başlangıcında bulunan ve dizi serbest bırakıldığında doğrulanan özel bir değere sahip bir bölgedir. Kırmızı bölgedeki değerler beklenenle eşleşmiyorsa arabellek taşması veya yetersiz çalışması meydana geldi. Bu, CheckJNI'nin iptal edilmesine neden olur. Zorunlu kopyalama modunu etkinleştirmek için:

adb shell setprop dalvik.vm.jniopts forcecopy

CheckJNI'nin yakalaması gereken bir hata örneği, GetPrimitiveArrayCritical elde edilen bir dizinin sonunun ötesine yazmaktır. Bu işlem Java yığınını bozabilir. Yazma işlemi CheckJNI kırmızı bölge alanı içindeyse ilgili ReleasePrimitiveArrayCritical çağrıldığında CheckJNI sorunu yakalar. Aksi takdirde, yazma işlemi Java yığınındaki bazı rastgele nesneleri bozar ve gelecekte GC çökmesine neden olabilir. Bozuk bellek bir referans alanıysa, GC hatayı yakalayabilir ve herhangi bir boşluk tarafından kapsanmayan <ptr> işaretlemeye çalışıldı hatasını yazdırabilir.

Bu hata, GC'nin boşluk bulamadığı bir nesneyi işaretlemeye çalıştığında ortaya çıkar. Bu kontrol başarısız olduktan sonra GC köklerin üzerinden geçerek geçersiz nesnenin kök olup olmadığını görmeye çalışır. Buradan iki seçenek vardır: Nesne kök veya kök olmayan bir nesnedir.

Geçersiz kök örneği

Nesnenin geçersiz bir kök olması durumunda bazı yararlı bilgiler yazdırır: 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

Bu durumda, com.google.gwt.collections.JavaReadableJsArray.get içindeki vreg=1 bir yığın referansı içermesi gerekir, ancak 0x2 adresinin geçersiz bir işaretçisini içerir. Bu geçersiz bir kök. Bu sorunu ayıklamak için yulaf dosyasında oatdump kullanın ve geçersiz kök içeren yönteme bakın. Bu durumda hatanın x86 arka ucundaki bir derleyici hatası olduğu ortaya çıktı. İşte sorunu düzelten değişiklik listesi: https://android-review.googlesource.com/#/c/133932/

Bozuk nesne örneği

Nesne bir kök değilse, aşağıdakine benzer bir çıktı yazdırılır:

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

Yığın bozulması geçersiz bir kök olmadığında hata ayıklamak zordur. Bu hata iletisi, yığında geçersiz nesneyi işaret eden en az bir nesnenin bulunduğunu gösterir.