المدمج في مراقبة الموارد من ذاكرة الوصول العشوائي المستخدمة في التطبيق

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

يمكن أن تكون أداة التحكم في الذاكرة المدمجة في حالة التشغيل أو الإيقاف (لتسجيل طلبات الذاكرة) ، وإمكانية تبديل الحالة المبرمجة تسمح لك بالتحكم في كمية البيانات المستلمة لموارد الذاكرة المخصصة وتحسينها.

مقدمة

تم تطوير نسبة كبيرة من أنظمة البرامج الحديثة باستخدام لغات البرمجة C # و Java وما شابه ذلك ، حيث يتم تنفيذ إدارة موارد RAM على مستوى النظام مع تقليل مسؤولية مطوري البرمجيات. مثال على أنظمة البرمجيات هذه هو نظام التصميم التلقائي بمساعدة الكمبيوتر من دلتا ديزاين الذي تم تنفيذه في C # في بيئة .net . من ناحية أخرى ، يتمتع برنامج أنظمة الأتمتة "بعمر افتراضي طويل" (يصل إلى عشرات السنين) ، مما يؤدي إلى الحاجة إلى الحفاظ على تقنيات إدارة ذاكرة RAM "القديمة" ، على وجه الخصوص ، عند دمج فئتي الأنظمة المذكورة في نظام تحكم مشترك.

لهذا السبب ، وحتى الآن ، تظل المشكلة الملحة في إنشاء وتطوير وصيانة تطبيقات البرمجيات المعقدة وظيفياً هي الحاجة إلى تحسين إدارة موارد ذاكرة الوصول العشوائي فيها. جنبا إلى جنب مع الأساليب الفعالة (المؤشرات الذكية ، جامعي القمامة) ، يستمر استخدام البرنامج الذي ينفذ طلبات موارد الذاكرة عبر المكالمات malloc ، calloc ، realloc ، مجانًا.
يوفر هذا النهج للمطورين سيطرة كاملة على إدارة ذاكرة الوصول العشوائي في التطبيق ، مع فرض مستوى عالٍ من المسؤولية عن الإفراج عن هذه الموارد في الوقت المناسب من أجل تجنب "التسريبات".

وكقاعدة عامة ، في المراحل الأولية لتطوير البرمجيات ، فإن مهمة تحديد حقائق الاستخدام غير الفعال لموارد الذاكرة ليست أولوية ، لأن بنية التطبيق شفافة للغاية. ومع ذلك ، تبدأ المشاكل في الظهور عند دمج مختلف المكونات الهيكلية والوظيفية للنظام مع مخططات معقدة للتحكم الموزع في موارد ذاكرة الوصول العشوائي وتبادل المعلومات بينها. تغيير الأجيال من مطوري النظام له أيضًا تأثير على حل مشكلات تحسين إدارة موارد RAM. نتيجة لذلك ، تبدأ الخصائص السلبية التالية في الظهور في التطبيق:

• توجد فجوة كبيرة بين الحجم الفعلي لذاكرة الوصول العشوائي المستهلكة وتقديرات المطورين ؛
• هناك زيادة خطية في الذاكرة الديناميكية المستخدمة أثناء تنفيذ التطبيق.

أسباب الاستخدام غير الفعال لذاكرة الوصول العشوائي في التطبيق هي عوامل مختلفة ، والتي هي مؤلفات للأحداث الأولية التالية:

• عدم تطابق طلبات وضع وإطلاق ذاكرة الوصول العشوائي ("التسرب") ؛
• انخفاض مستوى إعادة استخدام المناطق المحررة من ذاكرة الوصول العشوائي ، مما يؤدي إلى طلبات لمناطق جديدة (تجزئة).

تُظهر ممارسة تطوير تطبيقات البرامج وصيانتها باستخدام بنية معقدة ووظائف مطورة أن التحكم في استخدام موارد ذاكرة الوصول العشوائي فيها يجب أن يبدأ في أقرب وقت ممكن من أجل الحفاظ على السيطرة على هذه العملية. يمكنك التحكم في موارد ذاكرة التطبيق من خلال الحصول على منتجات البرامج المناسبة واستخدامها (على سبيل المثال ، valgrind ) ، أو عن طريق تطبيق وتضمين وسائل لاعتراض وتسجيل طلبات موارد RAM في رمز برنامج التطبيق.

فيما يلي مثال على أحد التطبيقات الممكنة لهذا النهج.

برامج التحكم المدمجة

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



يتضمن الشريط " B " سلسلة من الأحداث عند تخصيص الذاكرة التي تحدث عندما يكون وضع التحكم المدمج في وضع التشغيل. يتزامن هذا التسلسل تمامًا مع ما هو موضح سابقًا ، باستثناء أنه بعد تخصيص الذاكرة المطلوبة ، يتم تمرير التحكم إلى الدالة register_request () ، مما يوفر معلومات حول عنوان وحجم الذاكرة المخصصة وفقًا للطلب المقدم.

في الواقع ، يتم تنفيذ اعتراض وتسجيل الطلبات على موارد ذاكرة الوصول العشوائي بواسطة كائن memSupervisor ، الذي يتم إنشاؤه في مثيل واحد عن طريق استدعاء init_memSupervisor () والذي يمكن بعد ذلك تشغيله أو إيقاف تشغيله عن طريق المكالمات إلى enable_memSupervisor () أو disable_ memSupervisor () ، على التوالي.
تعتمد تقنية اعتراض طلبات موارد RAM على استخدام المتغيرات الثابتة لمكتبة جنو ، كما هو موضح في أجزاء التعليمات البرمجية التالية.





يتم تسجيل جميع الطلبات التي تمت معالجتها لموارد RAM في جدول خاص من السجلات ، يتم تخزين محتوياتها في سمة memSupervisor.memRegister. كل إدخال يحتوي على المعلومات التالية:



يرتبط كل سجل في الجدول بنقطة تحكم في رمز البرنامج ، بعد المرور الذي يتم تخصيص الذاكرة به وتسجيل الطلب.

يقوم منشئ التقرير النصي ( memSupervisor.genReport (file_name) ) بإنشاء تقرير باستخدام بيانات الجدول وكتابة المعلومات إلى الملف النصي المحدد (أو الإخراج إلى وحدة التحكم في التطبيق). سيسمح لك تنزيل بيانات التقارير إلى جدول MS Excel وضبطها وفقًا لذلك ، بالحصول على تمثيل رسومي لبيانات التقرير عن استخدام موارد RAM.

واجهة لعناصر التحكم المضمنة

يمكن تنفيذ مجموعة المعلومات حول طلبات التطبيق لموارد RAM من خلال تجميع ووضع وحدات الماكرو في التعليمات البرمجية المصدر للتطبيق التي يتم تجميعها فقط عند تعيين متغير البيئة المقابل.



يوجد أدناه جزء من رمز البرنامج الذي يوضح استخدام عناصر التحكم المضمنة.







فيما يلي توضيح لاستخدام الوسائل الموضحة للتحكم المضمن في موارد ذاكرة الوصول العشوائي (RAM) المطلوبة من قبل تطبيق 'foo' ، الذي يؤدي التتبع التلقائي للاتصالات على لوحات الدوائر المطبوعة. من أجل التحليل ، تم اختيار نموذج واضح ومناسب بدرجة كافية من التعرج ، والذي يعرض أبعاد ذاكرة الوصول العشوائي الديناميكية التي يطلبها التطبيق في عملية وضع التوصيلات على لوحة الدوائر المطبوعة.



يساعد هذا النموذج في تحديد المشكلات التالية لإدارة موارد ذاكرة الوصول العشوائي:

• في النقطتين "A" و "D" يجب أن يكونا بنفس حجم ذاكرة الوصول العشوائي المستخدمة تقريبًا
• يجب أن تكون الزيادة في حجم الذاكرة المطلوبة في مرحلة تنفيذ وضع الاتصال على نحو سلس. إذا لزم الأمر ، يجب التحكم في الخطوات الرئيسية لهذه المرحلة عن طريق تعيين نقاط التوقف في أجزاء التعليمات البرمجية المقابلة. يجب أن يؤدي الحذف القسري لجميع البيانات على الاتصالات الموضوعة إلى نفس حجم الذاكرة المستهلكة عند النقطتين "B" و "C"

يوضح الرسم البياني أدناه مشكلات إدارة الذاكرة في تطبيق 'foo' المذكور.

استنتاجات موجزة

يمكن استخدام الوسائل الموضحة للتحكم المتكامل في موارد ذاكرة الوصول العشوائي في الحالات التي تكون فيها منتجات البرامج المقابلة غير متوفرة وغير قابلة للتطبيق لأي سبب.

• تقوم أدوات التحكم المدمجة بتسجيل المعلومات حول موارد الذاكرة المطلوبة وتجميعها بأي درجة من الدقة والتفاصيل ؛
• تتيح لك القدرة على تبديل عناصر التحكم المضمنة بين الأوضاع النشطة وغير النشطة تكوينها لاستخراج وتحليل البيانات في أجزاء مختارة من كود برنامج التطبيق ؛
• تسمح عناصر التحكم المضمّنة باستبعادها الكامل من التطبيق عند تجميع الأخير دون تعيين معلمة التحويل البرمجي المناسبة ؛
• تنفيذ تحليل برنامجي لمحتوى التقارير الواردة بشأن تطبيق موارد ذاكرة الوصول العشوائي المستخدمة أثناء تنفيذ التطبيق والتحقق من هذا الأخير مع نسخ مرجعية يجعل من الممكن وضع إجراءات اختبار الانحدار للتطبيقات للكشف عن التدهور في استخدامهم لذاكرة الوصول العشوائي ؛
• كود البرنامج لهذا النوع من التحكم المدمج في ذاكرة الوصول العشوائي مفتوح لتوسيع قدراته والتكيف مع الظروف الخاصة لاستخدامه ؛
• العيب الرئيسي للأدوات الموصوفة هو الحاجة إلى تضمين رمز التحكم في الذاكرة المدمج في رمز التطبيق المراقبة.

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