اشکال زدایی مجموعه زباله ART

این صفحه نحوه اشکال زدایی مشکلات مربوط به صحت و عملکرد جمع آوری زباله (GC) Android Runtime (ART) را شرح می دهد. نحوه استفاده از گزینه‌های تأیید GC، شناسایی راه‌حل‌های خرابی تأیید GC، و اندازه‌گیری و رسیدگی به مشکلات عملکرد GC را توضیح می‌دهد.

برای کار با ART، به صفحات این بخش ART و Dalvik و فرمت اجرایی Dalvik مراجعه کنید. برای راهنمایی بیشتر در مورد تأیید رفتار برنامه، به تأیید رفتار برنامه در زمان اجرا Android (ART) مراجعه کنید.

نمای کلی ART GC

ART دارای چند طرح GC مختلف است که شامل راه اندازی زباله گردهای مختلف است. با شروع اندروید 8 (اوریو)، طرح پیش‌فرض کپی همزمان (CC) است. طرح GC دیگر، جابجایی علامت همزمان (CMS) است.

برخی از ویژگی های اصلی کپی همزمان GC عبارتند از:

• CC استفاده از یک تخصیص دهنده bump-pointer به نام RegionTLAB را امکان پذیر می کند. این یک بافر تخصیص محلی رشته ای (TLAB) به هر رشته برنامه اختصاص می دهد، که سپس می تواند اشیاء را با ضربه زدن به نشانگر "بالا"، بدون هیچ هماهنگی، به خارج از TLAB خود اختصاص دهد.
• CC با کپی همزمان اشیاء بدون توقف رشته های برنامه، یکپارچه سازی پشته را انجام می دهد. این امر با کمک یک مانع خواندن به دست می آید که خواندن مرجع را از پشته، بدون نیاز به هیچ گونه مداخله ای از سوی توسعه دهنده برنامه، قطع می کند.
• GC فقط یک مکث کوچک دارد که در زمان با توجه به اندازه پشته ثابت است.
• CC به یک نسل GC در اندروید 10 و بالاتر تبدیل شده است. این امکان جمع آوری اشیاء جوان را فراهم می کند، که اغلب به سرعت و با کمی تلاش غیرقابل دسترس می شوند. این امر با افزایش توان عملیاتی GC و به تاخیر انداختن قابل توجهی نیاز به انجام یک GC تمام هیپ کمک می کند.

GC دیگری که ART هنوز از آن پشتیبانی می کند CMS است. این GC همچنین از فشرده سازی پشتیبانی می کند، اما نه به طور همزمان. تا زمانی که برنامه به پس‌زمینه برود، از فشرده‌سازی اجتناب می‌شود، در این زمان رشته‌های برنامه برای انجام فشرده‌سازی متوقف می‌شوند. فشرده سازی همچنین زمانی ضروری می شود که تخصیص شی به دلیل تکه تکه شدن با شکست مواجه شود. در این صورت ممکن است برنامه برای مدتی به طور بالقوه پاسخگو نباشد.

از آنجایی که CMS به ندرت فشرده می شود، و بنابراین ممکن است اشیاء آزاد به هم متصل نباشند، از یک تخصیص دهنده مبتنی بر لیست آزاد به نام RosAlloc استفاده می کند. در مقایسه با RegionTLAB هزینه تخصیص بالاتری دارد. در نهایت، به دلیل تکه تکه شدن داخلی، استفاده از حافظه برای پشته جاوا می تواند برای CMS بیشتر از CC باشد.

تایید GC و گزینه های عملکرد

نوع GC را تغییر دهید

OEM ها می توانند نوع GC را تغییر دهند. فرآیند تغییر شامل تنظیم متغیر محیطی ART_USE_READ_BARRIER در زمان ساخت است. مقدار پیش‌فرض درست است، که جمع‌آورنده CC را با استفاده از مانع خواندن فعال می‌کند. برای CMS این متغیر باید به صراحت روی false تنظیم شود.

به‌طور پیش‌فرض، جمع‌کننده CC در اندروید 10 و بالاتر در حالت نسلی اجرا می‌شود. برای غیرفعال کردن حالت نسل، می توان از آرگومان خط فرمان -Xgc:nogenerational_cc استفاده کرد. همچنین، ویژگی سیستم را می توان به صورت زیر تنظیم کرد:

adb shell setprop dalvik.vm.gctype nogenerational_cc

جمع آوری کننده CMS همیشه در حالت نسلی اجرا می شود.

پشته را تأیید کنید

تأیید Heap احتمالاً مفیدترین گزینه GC برای اشکال زدایی خطاهای مربوط به GC یا خرابی heap است. فعال کردن تأیید heap باعث می‌شود که GC درستی پشته را در چند نقطه در طول فرآیند جمع‌آوری زباله بررسی کند. تأیید Heap همان گزینه‌هایی را به اشتراک می‌گذارد که نوع GC را تغییر می‌دهند. اگر فعال باشد، تأیید heap ریشه ها را تأیید می کند و اطمینان می دهد که اشیاء قابل دسترسی فقط به اشیاء قابل دسترسی دیگر ارجاع می دهند. تأیید GC با عبور از مقادیر -Xgc زیر فعال می شود:

• اگر فعال باشد، [no]preverify قبل از شروع GC، راستی‌آزمایی پشته را انجام می‌دهد.
• اگر فعال باشد، [no]presweepingverify قبل از شروع فرآیند جارو کردن زباله جمع‌آور، راستی‌آزمایی پشته را انجام می‌دهد.
• اگر فعال باشد، [no]postverify پس از پایان یافتن GC، راستی‌آزمایی پشته را انجام می‌دهد.
• [no]preverify_rosalloc ، [no]postsweepingverify_rosalloc و [no]postverify_rosalloc گزینه‌های GC اضافی هستند که فقط وضعیت حسابداری داخلی RosAlloc را تأیید می‌کنند. بنابراین، آنها فقط با کلکتور CMS که از اختصاص دهنده RosAlloc استفاده می کند، قابل اجرا هستند. موارد اصلی تأیید شده این است که مقادیر جادویی با ثابت های مورد انتظار مطابقت دارند و بلوک های آزاد حافظه همه در نقشه free_page_runs_ ثبت می شوند.

کارایی

دو ابزار اصلی برای اندازه گیری عملکرد GC وجود دارد، GC timing dumps و Systrace. همچنین یک نسخه پیشرفته از Systrace به نام Perfetto وجود دارد. روش بصری برای اندازه‌گیری مشکلات عملکرد GC استفاده از Systrace و Perfetto برای تعیین اینکه کدام GC باعث مکث طولانی یا پیش‌گیری رشته‌های برنامه می‌شوند، است. اگرچه ART GC در طول زمان به طور قابل توجهی بهبود یافته است، رفتار بد جهش دهنده، مانند تخصیص بیش از حد، هنوز هم می تواند باعث مشکلات عملکرد شود.

استراتژی جمع آوری

CC GC با اجرای یک GC جوان یا یک GC تمام پشته جمع آوری می شود. در حالت ایده آل GC جوان اغلب بیشتر اجرا می شود. GC مجموعه‌های CC جوان را تا زمانی انجام می‌دهد که توان عملیاتی (محاسبه شده توسط بایت‌های آزاد شده/ثانیه مدت زمان GC) چرخه جمع‌آوری تمام‌شده کمتر از میانگین توان عملیاتی مجموعه‌های CC full-heap باشد. وقتی این اتفاق می‌افتد، CC تمام پشته برای GC همزمان بعدی به جای CC جوان انتخاب می‌شود. پس از تکمیل مجموعه کامل هیپ، GC بعدی به CC جوان برمی گردد. یکی از عوامل کلیدی که باعث می‌شود این استراتژی عمل کند این است که CC جوان محدودیت ردپای پشته را پس از تکمیل آن تنظیم نمی‌کند. این باعث می شود که CC جوان بیشتر و بیشتر اتفاق بیفتد تا زمانی که توان عملیاتی کمتر از CC تمام هیپ باشد که در نهایت باعث رشد پشته می شود.

برای دریافت اطلاعات عملکرد GC از SIGQUIT استفاده کنید

برای دریافت زمان‌بندی عملکرد GC برای برنامه‌ها، SIGQUIT به برنامه‌های در حال اجرا ارسال کنید یا هنگام شروع یک برنامه خط فرمان، -XX:DumpGCPerformanceOnShutdown به dalvikvm ارسال کنید. هنگامی که یک برنامه سیگنال درخواست ANR ( SIGQUIT ) را دریافت می‌کند، اطلاعات مربوط به قفل‌ها، پشته‌های رشته و عملکرد GC را حذف می‌کند.

برای دریافت زمان‌بندی GC، از موارد زیر استفاده کنید:

adb shell kill -s QUIT PID

این یک فایل (با تاریخ و زمان به نام مانند anr_2020-07-13-19-23-39-817) در /data/anr/ ایجاد می کند. این فایل حاوی برخی موارد روگرفت ANR و همچنین زمان‌بندی GC است. با جستجوی Dumping conmulative timeings Gc می‌توانید زمان‌بندی GC را پیدا کنید. این زمان‌بندی‌ها چند چیز را نشان می‌دهند که ممکن است جالب باشد، از جمله اطلاعات هیستوگرام برای فازها و مکث‌های هر نوع GC. نگاه کردن به مکث ها معمولا اهمیت بیشتری دارد. مثلا:

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

این نشان می‌دهد که میانگین مکث 1.83 میلی‌ثانیه بوده است، که باید به اندازه‌ای کم باشد که باعث از دست رفتن فریم در اکثر برنامه‌ها نشود و نباید نگران‌کننده باشد.

یکی دیگر از حوزه‌های مورد علاقه، زمان تعلیق است، که اندازه‌گیری می‌کند که چقدر طول می‌کشد تا یک رشته به نقطه تعلیق برسد پس از درخواست GC برای تعلیق آن. این زمان در مکث های GC گنجانده شده است، بنابراین تعیین اینکه آیا مکث های طولانی به دلیل کندی GC یا معلق شدن آهسته نخ ایجاد می شود مفید است. در اینجا نمونه ای از زمان عادی برای تعلیق Nexus 5 آمده است:

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

زمینه های مورد علاقه دیگری نیز وجود دارد، از جمله کل زمان صرف شده و توان عملیاتی GC. مثال ها:

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

در اینجا نمونه‌ای از نحوه حذف زمان‌بندی GC یک برنامه در حال اجرا آورده شده است:

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

در این مرحله زمان‌بندی GC در داخل anr_2020-07-13-19-23-39-817 است. در اینجا نمونه ای از خروجی از 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

ابزارهایی برای تجزیه و تحلیل مشکلات صحت GC

موارد مختلف می تواند باعث خرابی در داخل ART شود. خرابی هایی که هنگام خواندن یا نوشتن در فیلدهای شی رخ می دهد ممکن است نشان دهنده خرابی پشته باشد. اگر GC هنگام کار از کار بیفتد، می تواند به فساد انبوه نیز اشاره کند. شایع ترین علت خرابی heap کد برنامه نادرست است. خوشبختانه، ابزارهایی برای اشکال‌زدایی GC و خرابی‌های مربوط به پشته وجود دارد، از جمله گزینه‌های تأیید heap مشخص‌شده در بالا، و CheckJNI.

بررسی JNI

CheckJNI حالتی است که چک های JNI را برای تأیید رفتار برنامه اضافه می کند. اینها به دلایل عملکرد به طور پیش فرض فعال نیستند. بررسی‌ها چند خطا را پیدا می‌کنند که می‌تواند باعث خرابی پشته‌ای شود، مانند استفاده از مراجع محلی و جهانی نامعتبر/ قدیمی. برای فعال کردن CheckJNI:

adb shell setprop dalvik.vm.checkjni true

حالت فورسکپی CheckJNI برای تشخیص نوشته های گذشته از انتهای مناطق آرایه مفید است. هنگامی که فعال است، فورسکپی باعث می شود که آرایه به توابع JNI دسترسی داشته باشد تا کپی هایی را با مناطق قرمز بازگرداند. ناحیه قرمز ناحیه‌ای در انتهای/شروع اشاره‌گر برگشتی است که دارای مقدار خاصی است که با آزاد شدن آرایه تأیید می‌شود. اگر مقادیر موجود در ناحیه قرمز با آنچه مورد انتظار است مطابقت نداشته باشد، بیش از حد بافر یا کم کاری رخ داده است. این باعث می شود که CheckJNI لغو شود. برای فعال کردن حالت فورسکپی:

adb shell setprop dalvik.vm.jniopts forcecopy

نمونه‌ای از خطایی که CheckJNI باید بگیرد، نوشتن از انتهای آرایه‌ای است که از GetPrimitiveArrayCritical به دست آمده است. این عملیات می تواند پشته جاوا را خراب کند. اگر نوشتن در ناحیه قرمز CheckJNI باشد، پس از فراخوانی ReleasePrimitiveArrayCritical مربوطه، CheckJNI مشکل را حل می کند. در غیر این صورت، نوشتن برخی از شی های تصادفی در پشته جاوا را خراب می کند و می تواند باعث خرابی GC در آینده شود. اگر حافظه خراب یک فیلد مرجع باشد، GC ممکن است خطا را دریافت کند و خطا را چاپ کند.

این خطا زمانی رخ می‌دهد که GC تلاش می‌کند شی‌ای را علامت‌گذاری کند که نمی‌تواند فضایی برای آن پیدا کند. پس از این که این بررسی ناموفق بود، GC از ریشه ها عبور می کند و سعی می کند ببیند آیا شی نامعتبر ریشه است یا خیر. از اینجا، دو گزینه وجود دارد: شی یک شی ریشه یا یک شی غیر ریشه است.

مثال ریشه نامعتبر است

در مواردی که شی یک ریشه نامعتبر است، اطلاعات مفیدی را چاپ می‌کند: 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

در این مورد، vreg=1 در داخل com.google.gwt.collections.JavaReadableJsArray.get قرار است حاوی یک مرجع پشته باشد، اما حاوی یک نشانگر نامعتبر از آدرس 0x2 است. این یک ریشه نامعتبر است. برای رفع اشکال این مشکل، از oatdump در فایل oat استفاده کنید و به روش با ریشه نامعتبر نگاه کنید. در این مورد، خطا یک اشکال کامپایلر در باطن x86 بود. این لیست تغییراتی است که آن را برطرف کرده است: https://android-review.googlesource.com/#/c/133932/

مثال شیء خراب

اگر شی روت نیست، خروجی مشابه چاپ زیر بگیرید:

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

وقتی heap corruption یک ریشه نامعتبر نیست، اشکال زدایی آن سخت است. این پیغام خطا نشان می دهد که حداقل یک شی در پشته وجود دارد که به شی نامعتبر اشاره می کند.