تصحيح أخطاء عملية جمع القمامة في ART

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

توضِّح هذه الصفحة كيفية تصحيح أخطاء صحة جمع المهملات (GC) ومشاكل الأداء في Android Runtime (ART). وتوضّح كيفية استخدام خيارات إثبات الملكية في "إعلانات Google"، وتحديد حلول لحالات تعذُّر إثبات الملكية في "إعلانات Google"، وقياس مشاكل أداء "إعلانات Google" والتعامل معها.

للعمل مع ART، اطّلِع على الصفحات في قسم ART وDalvik وتنسيق Dalvik القابل للتنفيذ. للحصول على مساعدة إضافية في التحقّق من سلوك التطبيق، يُرجى الاطّلاع على مقالة التحقّق من سلوك التطبيق على "مُشغِّل Android للوقت الفعلي" (ART).

نظرة عامة على ART GC

تتضمّن ART بعض خطط إدارة الذاكرة المختلفة التي تتألف من تشغيل أدوات جمع مختلفة للملفّات المؤقتة. بدءًا من الإصدار 8 من نظام التشغيل Android (Oreo)، تكون الخطة التلقائية هي "النسخ المتزامن". خطة تنظيف الذاكرة الأخرى هي Concurrent Mark Sweep (CMS).

في ما يلي بعض السمات الرئيسية لميزة "جمع البيانات المتزامنة":

• يتيح CC استخدام أداة تخصيص مؤشر الزيادة المُسماة RegionTLAB. يؤدي ذلك إلى تخصيص ملف تخزين مؤقت لعمليات التخصيص (TLAB) على مستوى الخيط لكل سلسلة محادثات في التطبيق، والتي يمكنها بعد ذلك تخصيص عناصر خارج ملف التخزين المؤقت لعمليات التخصيص (TLAB) عن طريق تعديل المؤشر "top"، بدون أي مزامنة.
• تُجري أداة CC عملية إزالة التجزئة في الحِزمة عن طريق نسخ العناصر بشكل متزامن بدون إيقاف مؤقت لخيوط التطبيق. ويتم تحقيق ذلك بمساعدة حاجز القراءة الذي يعترض عمليات قراءة المراجع من ملف heap، بدون الحاجة إلى أي تدخل من مطوّر التطبيق.
• لا يتضمّن "جمع القمامة" سوى فترة توقف صغيرة واحدة، وهي ثابتة في الوقت المناسب بالنسبة إلى حجم الحِزمة.
• تم توسيع نطاق CC ليصبح أداة لإدارة الذاكرة من الجيل التالي في Android 10 والإصدارات الأحدث. ويتيح هذا الإجراء جمع الأجسام الجديدة التي يصبح من الصعب الوصول إليها غالبًا بسرعة كبيرة، وذلك بدون جهد كبير. ويساعد ذلك في زيادة معدل نقل البيانات في عملية جمع القمامة وتأخير الحاجة إلى تنفيذ عملية جمع قمامة للمساحة الكاملة بشكل كبير.

أما GC الأخرى التي لا يزال ART يتوافق معها، فهي CMS. يتيح "نظام معالجة القمامة" هذا أيضًا التجميع، ولكن ليس بشكل متزامن. ويتم تجنُّب التجميع إلى أن ينتقل التطبيق إلى الخلفية، وعندها يتم إيقاف مؤقت لخيوط التطبيق لتنفيذ التجميع. وتصبح التجميعات ضرورية أيضًا عند تعذُّر تخصيص عنصر بسبب التجزئة. في هذه الحالة، قد يتوقف التطبيق عن الاستجابة لبعض الوقت.

وبما أنّ نظام إدارة المحتوى نادرًا ما يُجمِّع البيانات، وبالتالي قد لا تكون العناصر الفارغة متّصلة، يستخدم دلاّلاً يستند إلى قائمة العناصر الفارغة يُسمى RosAlloc. وتبلغ تكلفة التخصيص فيها مبلغًا أعلى مقارنةً بـ RegionTLAB. أخيرًا، بسبب التجزئة الداخلية، يمكن أن يكون استخدام الذاكرة في كومّة Java أعلى في نظام إدارة المحتوى (CMS) مقارنةً بـ CC.

خيارات الأداء وإثبات الملكية في "إعلانات Google"

تغيير نوع "جمع القمامة"

يمكن للمصنّعين الأصليين للأجهزة تغيير نوع GC. تشمل عملية التغيير ضبط متغيّر البيئة ART_USE_READ_BARRIER في وقت الإنشاء. القيمة التلقائية هي true، ما يؤدي إلى تفعيل أداة جمع عناوين IP للعملاء لأنّها تستخدم حاجز القراءة. بالنسبة إلى نظام إدارة المحتوى، يجب ضبط هذا المتغيّر على خطأ صراحةً.

يعمل "مجمع CC" تلقائيًا في وضع الجيل في Android 10 والإصدارات الأحدث. لإيقاف وضع الإنشاء، يمكن استخدام الوسيطة -Xgc:nogenerational_cc لسطر الأوامر. بدلاً من ذلك، يمكن ضبط سمة النظام على النحو التالي:

adb shell setprop dalvik.vm.gctype nogenerational_cc

التحقّق من الحِزمة

من المحتمل أنّ عملية التحقّق من الذاكرة هي الخيار الأكثر فائدة لجمع البيانات من أجل تصحيح أخطاء جمع البيانات أو تلف الذاكرة. يؤدي تفعيل ميزة التحقّق من الذاكرة المحجوزة مؤقتًا إلى أن يتحقّق GC من صحة الذاكرة المحجوزة مؤقتًا في بضع نقاط أثناء عملية جمع القمامة. تتشارك عملية التحقّق من ذاكرة التخزين المؤقت الخيارات نفسها التي تؤدي إلى تغيير نوع "جمع القمامة". في حال تفعيل ميزة التحقّق من الحِزم، تتحقّق هذه الميزة من الجذور و تؤكّد من أنّ العناصر التي يمكن الوصول إليها تشير إلى عناصر أخرى يمكن الوصول إليها فقط. يتم تفعيل عملية التحقّق من GC من خلال إدخال قيم -Xgc التالية:

• في حال تفعيل [no]preverify، يُجري هذا الإجراء عملية التحقّق من الحِزمة قبل بدء عملية جمع القمامة.
• في حال تفعيله، يُجري [no]presweepingverify عملية التحقّق من الحِزمة قبل بدء عملية كنس أداة جمع المهملات.
• في حال تفعيل هذه الميزة، يُجري [no]postverify عملية التحقّق من الحِزمة بعد انتهاء عملية جمع القمامة.
• ‫[no]preverify_rosalloc و[no]postsweepingverify_rosalloc و [no]postverify_rosalloc هي خيارات إضافية لجمع البيانات في "إدارة الذاكرة في Java" (GC) للتحقّق فقط من حالة المحاسبة الداخلية لـ RosAlloc. لذلك، لا يمكن استخدامها إلا مع مجمع رسائل التحكم في الشبكة (CMS) الذي يستخدم أداة تخصيص RosAlloc. إنّ العناصر الرئيسية التي يتم التحقّق منها هي أنّ القيم السحرية تتطابق مع الثوابت المتوقّعة، وأنّ كلّ وحدات الذاكرة الفارغة مسجّلة في خريطة free_page_runs_.

الأداء

هناك أداتان رئيسيتان لقياس أداء "جمع القمامة"، وهما توقيت "جمع القمامة" وعمليات تسجيل الذاكرة وSystrace. يتوفّر أيضًا إصدار متقدّم من Systrace يُسمى Perfetto. إنّ الطريقة المرئية لقياس مشاكل أداء جمع القمامة هي استخدام Systrace وPerfetto لتحديد عمليات جمع القمامة التي تتسبّب في فترات توقف طويلة أو تسبق سلاسل مهام التطبيق. على الرغم من أنّ أداة إدارة الذاكرة في ART قد تحسّنت بشكل كبير بمرور الوقت، إلا أنّ السلوك السيئ لوحدة التحوّل ، مثل التخصيص المفرط، قد يستمر في التسبب في مشاكل في الأداء.

استراتيجية جمع البيانات

تجمع ميزة "جمع القمامة في ذاكرة التخزين المؤقت" (CC GC) إما من خلال تشغيل ميزة "جمع القمامة للشباب" أو ميزة "جمع القمامة في ذاكرة التخزين المؤقت بالكامل". من الأفضل تشغيل GC الشاب بشكلٍ متكرّر. يُجري "نظام جمع القمامة" عمليات جمع ذاكرة التخزين المؤقت لوقت التشغيل القصير إلى أن يصبح معدل نقل البيانات (يتم احتسابه بالبايت المُستغنَى عنه في الثانية من مدة "نظام جمع القمامة") لدورة الجمع التي انتهت للتو أقل من متوسط معدل نقل البيانات لعمليات جمع ذاكرة التخزين المؤقت للمساحة الكاملة. عند حدوث ذلك، يتم اختيار CC للمساحة الكاملة في الذاكرة في عملية جمع القمامة المتزامنة التالية بدلاً من CC للعناصر الجديدة. بعد اكتمال عملية جمع الذاكرة الكاملة، يتم تبديل عملية جمع القمامة التالية مجددًا إلى CC الجديدة. من العوامل الرئيسية التي تجعل هذه الاستراتيجية ناجحة أنّ CC الشاب لا يعدّل حدّ مساحة الذاكرة المحجوزة بعد اكتمالها. ويؤدي ذلك إلى حدوث عمليات جمع القمامة الجديدة بشكلٍ متزايد وأكثر تكرارًا إلى أن يصبح معدل نقل البيانات أقل من عمليات جمع القمامة في الحزمة الكاملة، ما يؤدي في النهاية إلى توسيع الحزمة.

استخدام SIGQUIT للحصول على معلومات عن أداء جمع القمامة

للحصول على أوقات أداء GC للتطبيقات، أرسِل SIGQUIT إلى التطبيقات التي تعمل حاليًا أو أرسِل -XX:DumpGCPerformanceOnShutdown إلى dalvikvm عند بدء برنامج سطر أوامر. عندما يتلقّى التطبيق إشارة طلب ANR‏ (SIGQUIT)، يُفرِغ التطبيق معلومات متعلّقة بقفلاته ومخطّطات سلاسل المهام وأداء جمع القمامة.

للحصول على نُسخ مجمّعة من أوقات جمع القمامة، استخدِم:

adb shell kill -s QUIT PID

يؤدي ذلك إلى إنشاء ملف (يتضمّن التاريخ والوقت في الاسم، مثل anr_2020-07-13-19-23-39-817) في /data/anr/. يحتوي هذا الملف على بعض عمليات تفريغ أخطاء ANR بالإضافة إلى أوقات جمع البيانات. يمكنك تحديد موقع أوقات جمع البيانات المؤقتة عن طريق البحث عن تجميع أوقات جمع البيانات المؤقتة التراكمية. تعرض هذه التوقيتات بعض المعلومات التي قد تهمّك، بما في ذلك معلومات الرسم البياني الشريطي لمراحل كل نوع من أنواع جمع القمامة ووقت التوقف. وعادةً ما تكون الفواصل أكثر أهمية من حيث الاطّلاع عليها. مثلاً:

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

يشير ذلك إلى أنّ متوسط وقت الإيقاف المؤقت كان 1.83 ملي ثانية، وهو وقت منخفض بما يكفي لعدم مشاهدة بعض اللقطات في معظم التطبيقات، ولا يشكّل ذلك مصدر قلق.

ومن الجوانب الأخرى التي تهمّك هي وقت التعليق، الذي يقيس المدّة التي يستغرقها خيط معيّن للوصول إلى نقطة تعليق بعد أن يطلب منه 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

في ما يلي مثال على كيفية تفريغ أوقات جمع القمامة لتطبيق قيد التشغيل:

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

في هذه المرحلة، تكون أوقات جمع البيانات ضمن anr_2020-07-13-19-23-39-817. في ما يلي مثال على الإخراج من "خرائط Google":

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

أدوات لتحليل مشاكل صحة "جمع القمامة"

يمكن أن تؤدي عوامل مختلفة إلى حدوث أعطال داخل ART. إنّ الأعطال التي تحدث عند قراءة حقول الكائنات أو الكتابة فيها قد تشير إلى تلف الحِزمة. إذا تعطّل GC أثناء تشغيله، قد يشير ذلك أيضًا إلى تلف الحِزمة. إنّ السبب الأكثر شيوعًا لتلف الحِزمة هو رمز التطبيق غير الصحيح. لحسن الحظ، تتوفّر أدوات لتحديد وإصلاح أخطاء "جمع القمامة" والأعطال المرتبطة بالمساحة المتوفّرة للبرامج، بما في ذلك خيارات التحقّق من المساحة المتوفّرة للبرامج المحدّدة أعلاه وCheckJNI.

CheckJNI

CheckJNI هو وضع يضيف عمليات تحقّق JNI للتحقّق من سلوك التطبيق، ولا تكون هذه العمليات مفعّلة بشكلٍ تلقائي لأسباب تتعلّق بالأداء. ترصد عمليات التحقّق بعض الأخطاء التي قد تؤدي إلى تلف الحِزمة، مثل استخدام إشارات محلية وعامة غير صالحة أو قديمة. لتفعيل CheckJNI:

adb shell setprop dalvik.vm.checkjni true

يُعدّ وضع forcecopy في CheckJNI مفيدًا لرصد عمليات النسخ التي تتجاوز نهاية مناطق المصفوفة. عند تفعيل forcecopy، يؤدي ذلك إلى أن يطلب الصفيف الوصول إلى وظائف JNI لعرض نُسخ تتضمّن مناطق حمراء. المنطقة الحمراء هي منطقة في نهاية/بداية المؤشر الذي تم إرجاعه والتي تحتوي على قيمة خاصة، ويتم التحقّق منها عند تحرير الصفيف. إذا كانت القيم في المنطقة الحمراء لا تتطابق مع القيم المتوقّعة، يعني ذلك أنّه حدث تجاوز سعة التخزين أو نقص فيها. يؤدي ذلك إلى إيقاف CheckJNI. لتفعيل وضع forcecopy:

adb shell setprop dalvik.vm.jniopts forcecopy

من الأمثلة على الأخطاء التي من المفترض أن يرصدها CheckJNI هي الكتابة بعد نهاية مصفوفة تم الحصول عليها من GetPrimitiveArrayCritical. يمكن أن تؤدي هذه العملية إلى تلف حِزمة Java. إذا كانت عملية الكتابة تتم ضمن منطقة CheckJNI الحمراء، سيرصد CheckJNI المشكلة عند استدعاء ReleasePrimitiveArrayCritical المقابل. بخلاف ذلك، يؤدي الإجراء إلى فساد بعض العناصر العشوائية في ملف heap في Java، ويمكن أن يؤدي ذلك إلى تعطُّل عملية جمع القمامة في المستقبل. إذا كانت الذاكرة المفسّخة هي حقل مرجع، قد يرصد "عامل جمع القمامة" الخطأ ويطبع الخطأ Tried to mark <ptr> not contained by any spaces.

يحدث هذا الخطأ عندما يحاول 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

عندما لا يكون تلف الحِزمة ناتجًا عن سبب غير صالح، يكون من الصعب تصحيح الأخطاء. تشير رسالة الخطأ هذه إلى أنّه كان هناك عنصر واحد على الأقل في الحِزمة كان يشير إلى العنصر غير الصالح.