بعون الله نبدأ الدرس السادس من سلسلة دروس هيا نتعلم بعض المبادء لنطرق باب الإحتراف
أتمنى من الله أن يمدكم بجلد لتقوموا بقراءة هذه الدروس بعناية
عملية التنفيذ المدارة - Managed Execution Process
تتضمن عملية التنفيذ المدارة Managed Execution Process الخطوات التالية:
• اختيار المترجم - Choosing a Compiler
لكي تحصل على الفوائد المزودة في إستدعاءات وقت تشغيل اللغة المشترك Common Language Runtime (CLR)، يجب عليك أن تستعمل واحد أو أكثر من مجمعات Compilers اللغة التي تستهدف وقت التشغيل Runtime، مثل مجمعات فيجول بيسك Visual Basic، C# أو كما تلفظ سي شارب C Sharp، فيجول سي ++ Visual C++، جي سكريبت JScript، أو العديد من مجمعات الفريق الثالث مثل إيفل Eiffel، بيرل Perl، أو كوبل COBOL.
لأن بيئة التنفيذ المتعددة اللغات، تدعم وقت التشغيل Runtime بتنوع عريض من أنواع البيانات وميزات اللغة. مجمع اللغة Compiler الذي استخدمته في تصميمك يحدد أي ميزات وقت التشغيل متوفرة وأنت تصمم شيفرتك و تستعمل تلك الميزات. مجمعك Your Compiler، لا يتواجد في وقت التشغيل Runtime، هو يؤسس فقط عبارات Syntax شيفرتك التي يجب أن تستخدم. إذا تطبيقك يجب أن يكون صالح للاستعمال بالكامل بمكونات كتبت في لغات أخرى، أنواعك المصدرة المكونة يجب أن تعرض مواصفات وميزات تلك الأنواع المتضمنة في تطبيقك للغتك أما الأنواع المعرفة مسبقاً في مواصفات اللغة المشتركة Common Language Specification (CLS) فهي ليست بحاجة لتعريف.
• الترجمة إلى لغة مايكروسوفت الوسيطة - Compiling to Microsoft intermediate language
وأطلق عليها أيضاً اسم الشيفرة المدارة Management Code. تتلخص هذه التقنية بما يلي:
عندما يقوم المجمع Compiler بترجمة شيفرتك المدارة، يقوم المجمع Compiler بترجمة الأوامر التي قمت بكتابتها إلى لغة وسيطة MSIL التي هي مجموعة أوامر مستقلة عن أوامر المعالج الأصلية التي يمكن أن تحول بشكل كفؤ إلى رموز المعالج الأصلية. تتضمن لغة MSIL أوامر لتحميل وتخزين و تهيئة واستدعاءات لوظائف الكائنات، وأيضا أوامر للعمليات الحسابية والمنطقية وجريان التحكم و وصول مباشر إلى الذاكرة و معالجة الاستثناءات وعمليات أخرى. قبل أن يكون الكود جاهز للعمل يجب على MSIL أن تحوله إلى لغة المعالج الأصلية، وأصبح هذا النوع من الترجمة مصطلح أطلق عليه الترجمة في الوقت المناسب أو الترجمة في زمن التشغيل just-in-time (JIT) Compile لأن الأوامر التي نقوم بكتابتها تحتوي على إستدعاءات وقت تشغيل اللغة المشترك Common Language Runtime (CLR) وهذه الأوامر تختلف كما ذكرنا سابقاً من معالج لآخر ومن نظام لأخر، ويأتي هنا دور اللغة الوسيطة لترجمة نفس الأوامر التي قمت بكتابتها إلى أوامر تفهمها معمارية النظام المضيف لهذا التطبيق التي تدعمها اللغة الوسيطة MSIL.
عند ترجمة التطبيق ينتج لغة وسيطة MSIL وتنتج أيضاً معلومات Metadata، وهذه المعلومات هي عبارة عن توصيف للأنواع التي قمت باستخدامها في الشيفرة وتتضمن تعريف دقيق لكل نوع مستخدم وتوقيع لجميع أعضاء (وظائف) النوع والأعضاء (الوظائف) هي عبارة عن إشارة للشيفرة التي قمت بكتابتها أو استدعائها ولبعض الأوامر التي تحتاج للترجمة في وقت التنفيذ. اللغة الوسيطة MSIL و معلومات الأنواع Metadata تخزن داخل ملفات ثنائية يطلق على هذه الملفات اسم الملفات التنفيذية القابلة لنقل Portable Executable (PE) File وهذه النوعية من الملفات مستندة على التقنية PE و على تقنية صيغة ملفات الكائنات العامة Common Object File Format (COFF) التي استخدمت سابقاً. وهذا النوع من صيغ الملفات يلائم MSIL & Metadata مما يمكن نظام التشغيل التعرف على أماكن تواجدها وقت التشغيل اللغة المشترك Common Language Runtime (CLR).
• ترجمة اللغة الوسيطة إلى اللغة الأصلية - Compiling MSIL to Native Code
قبل أن تكون قادر على تشغيل تطبيقك المكتوب بلغة مايكروسوفت الوسيطة Microsoft Intermediate Language يجب أن يحول الكود المكتوب في داخله إلى الأوامر الأصلية Native Code، التي يمكن لوحدة المعالجة المركزية أن تفهم هذه الأوامر وتشغيلها برغم اختلاف الهندسة المعمارية لهذا الحاسب وهذا التحويل يتم من قبل مكاتب اللغة لترجمة في الوقت المناسب .NET Framework just-in-time (JIT) Compiler لأن وقت التشغيل اللغة المشترك Common Language Runtime (CLR) مجهزه بترجمة في وقت التشغيل just-in-time (JIT) compiler ولكل معمارية وحدة معالجة مركزية يوجد لها (JIT) مدعومة، يمكن للمطورين أن يكتبوا مجموعة MSIL التي يمكن أن تصبح مجموعة من الأوامر التي تترجم في وقت التشغيل (JIT) compiler وتستطيع العمل على الحواسب ذات الهندسة المعمارية المختلفة. من جهة أخرى يجب أن نفهم مايلي، تطبيقك الذي يحتوي على الشيفرة المدارة Management Code سيعمل فقط على نظام تشغيل محدد إذا قمت باستدعاء أوامر هذا النظام Platform-Specific Native APIs لأنه كما ذكر سابقاً بأن معمارية أنظمة التشغيل تختلف من نظام لآخر، أو إذا قمنا باستدعاء مكتبة أنواع محددة Platform-Specific Class Library.
التقنية الحديثة التي تتحدث عنها الترجمة في وقت التنفيذ just-in-time (JIT) compiler لو فكرنا فيها قليلاً لوجدنا أنها سوف تقوم على إبطاء التطبيقات التي تستخدم هذه التقنية فقامت شركة مايكروسوفت على تطوير هذه التقنية فمقاطع الكود التي تقوم في ترجمتها على الأوامر الأصلية التي تفهمها الهندسة المعمارية المضيفة لتطبيقك أثناء التشغيل فبدلاً من حذفها عند الانتهاء منها تقوم بتخزينها في ذاكرة الحاسب لتكون جاهزة للطلب في المرة القادمة. ينشئ محمل Loader التطبيق جدول ويقوم بتخزين عناوين لمواقع المقاطع التي قام بترجمتها أو لمناهج أحد الكائنات ليقوم بربط كل استدعاء أو حين تنشئ كائن جديد في شيفرتك من كائن قد ترجمة مناهجه مسبقاً .كما قلنا مسبقاً فإن الاستدعاء الأول لهذه المناهج يجب أن يترجم عن طريق المترجم أو الترجمة أثناء التشغيل just-in-time (JIT) compiler، الذي يقوم عل تحويل MSIL لذلك المنهج إلى اللغة الأصلية Native Code ويقوم بتعديل عنوان هذا المنهج إلى عنوان المنهج الذي قام المترجم بتحويله. والاستدعاءات المقبلة لهذا المنهج أو لهذا المقطع من الشيفرة لن يمر عبر الترجمة الفورية للشيفرة just-in-time (JIT) compiler مما يساعد في تخفيض الوقت لاستدعاء هذه الشيفرة مما يؤدي لتخفيض من أهمية العقبة التي وقفت في وجهة هذه التقنية.
يزود وقت التشغيل Runtime نمط آخر من أنماط التجميع Compilation يطلق عليه الترجمة في وقت التركب للشيفرة Install-Time code generation.تحول اللغة الوسيطة MSIL في نمط الترجمة في وقت التركب للشيفرة Install-Time code generation إلى الشيفرة الأصلية Native Code كما يعمل المجمع النظامي للترجمة في وقت التشغيل (JIT) compiler، لكنه يحول وحدات أكبر من الشيفرة في نفس الوقت،ويخزن الشيفرة الأصلية Native Code الناتجة في مجمعات Assemblies وتكون جاهزة للاستعمال عند تحميل وتنفيذ التجمع Assembly بعد ذلك. عندما نستخدم نمط الترجمة في وقت التركب للشيفرة Install-Time code generation، كل التجمع Assemblies الذي يركب يحول إلى الشيفرة الأصلية Native Code، يأخذ في الحسبان تجميع معرفة حول التجمعات Assemblies الأخرى التي ركبت مسبقاً. تحميل ملفات النتيجة في هذا النمط يجعله يعمل بشكل أسرع من اختيارنا لنمط الترجمة أثناء التشغيل just-in-time (JIT) compiler.
• تشغيل الشيفرة – Running Code
يزود وقت تشغيل اللغة المشترك Common Language Runtime (CLR) البنية التحتيه التي تمكن التنفيذ المدار Managed Execution أن يحدث ومجموعة متنوعة أيضا من الخدمات التي يمكن أن تستعمل خلال التنفيذ. قبل أن تكون قادر على تنفيذ الشيفرة، يجب أن تقوم بترجمتها إلى لغة المعالج المحدد. كل طريقة في لغة مايكروسوفت الوسيطة Microsoft intermediate language (MSIL) يجب على المجمع تحويله إلى اللغة الأصلية Native Code فقط في الترجمة أثناء وقت التشغيل just-in-time (JIT) compiler وعندما تطلب أول مرة، و في المرات القادمة لا يقوم المجمع بعملية التحول ثانية بل تطلب من المنطقة التي خزنت فيها كما تحدثنا مسبقاً. ويبقى المجمع يطلب عملية الترجمة أثناء التشغيل just-in-time (JIT) compiler للشيفرة المدارة حتى يتم الانتهاء من تنفيذ جميع هذه الشيفرة أو يتم توقف عمل التطبيق0
خلال التنفيذ، الشيفرة المدارة تستلم خدمات مثل مجمع النفايات Garbage Collection، أمن Security، إمكانية لوجود شيفره غير مداره Interoperability With Unmanaged Code، دعم تنقيح الشيفرة Debugging، تحسين لتوزيع ودعم لنقل الشيفرة والتطبيقات Deployment and Versioning .
في مايكروسوفت ويندوز إكس بي Windows XP، محمل نظام التشغيل يتأكد من الوحدات المدارة Managed Modules باختبار إحدى قيم أجزاء Bits الترويسه لملفات المكتوبة في صيغة ملفات الكائنات المشتركه Common Object File Format (COFF). يشير هذا المكان (Bit) إلى أن محتويات هذا الملف وحدة مدارة Managed Modules أم لا. إذا تأكد محمل النظام من أن الملف يحوي وحدات مدارة Managed Modules، يقوم بتحميل MSCORE.DLL وهي أحد المكاتب المسئولة عن ترجمة الشيفرة المدارة Managed Code ويقوم استدعاء الوظيفتين _CorValidateImage and _CorImageUnloading وهما أحد أعضاء هذه المكتبة ومهمة هاتين الوظيفتين إبلاغ محمل النظام عند تحميل Loaded وإلغاء تحميل Unloaded الوحدات المدارة. تنجز الوظيفة التي يقوم المحمل باستدعائها _CorValidateImage المهام التالية:
1- يضمن بأن الشيفرة هي شيفرة مداره Managed Code صحيحة.
2- يقوم بتغير نقطة الدخول في الصورة (الشيفرة المدارة Managed Code) إلى نقطة دخول في وقت التشغيل.
في نظام التشغيل ويندوز 64 Windows 64، تقوم الوظيفة _CorValidateImage بتعديل الصورة التي في الذاكرة بتحويلها من صيغة ملفات PE 32 إلى صيغة ملفاتPE32+ .
بعون الله نبدأ الدرس السابع من سلسلة دروس هيا نتعلم بعض المبادء لنطرق باب الإحتراف
أتمنى من الله أن يمدكم بجلد لتقوموا بقراءة هذه الدروس بعناية
الإدارة الآلية للذاكرة - Automatic Memory Management
الإدارة الآلية للذاكرة Automatic Memory Management هي من أحد الخدمات التي يقوم وقت التشغيل اللغة المشترك Common Language Runtime (CLR) بتزويدها خلال عملية التنفيذ المدارة Managed Execution Process . جامع النفايات Garbage Collector التابع لوقت تشغيل اللغة المشترك Common Language Runtime (CLR) يقوم بإدارة جميع الحجوزات والتقسيمات التي أنشأتها التطبيقات في الذاكرة ليقوم على تحريره حين تنتهي التطبيقات من استخدامها. وتعني الإدارة الآلية للذاكرة Memory Management للمطور الذي اعتاد على كتابة شيفرة ليقوم بعملية إدارة الذاكرة. وكان هذا العمل شاق جداً وكان المبرمج بدلاً من أن يحل المشكلة التي جاء بها يفاجئ بمشاكل إدارة الذاكرة وإدارة الذاكرة Memory Management تعني أنه يجب على المطور أن يقوم بحذف جميع المصادر التي قام باستخدامها لكي لا يسبب بعملية هدر لا متوقع في الذاكرة أو كما يقال إنشاء ثقب أو تسريب في الذاكرة Memory Leaks أو الكتابة على مناطق في الذاكرة قمت على تحريرها مسبقاً فجاءت تقنية الإدارة الآلية الذاكرة Automatic Memory Management لتريح المطور من هذه المشاكل كلها وفي مايلي شرح لمبادئ عمل جامع النفاياتGarbage Collector من إدارة وتحرير:
• تقسيم الذاكرة - Allocating Memory
عندما تبدأ في عملية جديدة، يحجز وقت التشغيل Runtime منطقة متجاورة Contiguously من فضاء عناوينAddress Space العملية. طريقة حجز العناوين الجديدة New Address في فضاء عنوان Address Space العملية يدعو الكومة المدارة Managed Heap. تحتفظ الكومة المدارة Managed Heap بمؤشر Pointer إلى العنوان المتاح أي العنوان الذي لم يتم حجزه من قبل أي كائن حيث سيتم تخصيص مكان للكائن Object القادم في الكومة Heap ويطلق على هذا العنوان العنوان الأساسي Base Address. بشكل مبدئي، هذا المؤشر هو عبارة عن عنوان رئيسي Base Address للكائن Object وهو أحدا لعناوين المتواجدة في الكومة المدارة Managed Heap. نستنتج مما يلي أن أي كائن Object نستطيع التعامل معه عن طريق العنوان Pointer نستطيع أن نخصص له مكان في الكومة المدارة Managed Heap وهذه الكائنات Objects هي عبارة عن أنواع New Types جديدة نطلق عليها الأنواع ذات المرجع Reference Types. عندما ينشئ أي تطبيق أول كائن من نوع ذا مرجع Reference Types، يأخذ هذا العنوان أول عنوان Pointer متاح وهو عنوان القاعدةBase Address في الكومة المدارة Managed Heap. عندما ينشئ التطبيق كائن Object جديد،يقوم جامع النفايات بشكل فوري بتخصيص ذاكره لهذا الكائن Object في فضاء العنوان Address Space ويكون بعد عنوان Pointer الكائن الأول First Object. طالما يوجد مكان متوفر في فضاء العناوين Address Space، يستمر جامع النفايات Garbage Collector بتخصص فضاء Space للكائنات الجديدة New Object في هذا الأسلوب الذي تحدثنا عنه.
تخصيص الذاكرة في الكومة المدارة Managed Heap أسرع من تخصيص الذاكرة الغير مدار Unmanaged Memory Allocation. لأن وقت التشغيل Runtime يخصص ذاكرة للكائن Object بإضافة مؤشر Pointer جديد إلى المؤشرات Pointers الموجودة، وهذه الطريقة على الأغلب أسرع من تخصيص الذاكرة في المكدس Stack. بالإضافة أن الكائنات Objects الجديدة التي تحجز مؤشراتها Pointers بشكل متتالي Contiguously تخزن بشكل متتالي أيضاَ في الكومة المدارة Managed Heap، يمكن للتطبيق أن يستدعي الكائنات Objects في هذه الحالة بشكل سريع جداً.
• تحرير الذاكرة - Releasing Memory
يحسن محرك تحديد الوقت مهمة جامع النفايات Garbage Collector ليقوم بأفضل أداء فهو يقوم باختيار الوقت المناسب ليقوم بعملية جمع وتحرير الذاكرة الغير مستخدمة. عندما يقوم جامع النفايات Garbage Collector بإنجاز مهمة جمع النفايات، فهو يقوم بتحرير جميع مناطق الذاكرة التي لم تعد مستخدمة من قبل التطبيق. يستطيع جامع النفايات Garbage Collector تحديد الكائنات Objects الغير مستخدمة عن طريق اختبار جداول مؤشرات Root التطبيق. وجميع التطبيقات تملك مجموعة من جداول المؤشرات Roots. كل جدول للمؤشرات Root أما يشير إلى مجموعة من الكائنات Objects في الكومة المدارة Managed Heap أو مجموعة من الكائنات Objects الغير مستخدمة. جداول مؤشرات Roots التطبيق تتضمن مؤشرات Pointers لكائنات Objects عامة Public وساكنة Static ومتحولات محلية Local Variables ومرجع لكائنات Reference Objects تكون عبارة عن بارامترات Parameters في مكدس Stack وسجلات وحدة المعالجة المركزية CPU Registers. جامع النفاياتGarbage Collector يملك أمكانية الوصول إلى قائمة جداول المؤشرات List Roots النشطة التي تكون قيد الاستخدام من قبل الترجمة في الوقت المناسب just-in-time (JIT) compiler ووقت التشغيل Runtime يحتفظان بها. جامع النفايات Garbage Collector يقوم باستخدام هذه القائمة List Roots ليقوم بعملية اختبار لجداول مؤشرات Roots التطبيق ويقوم بإنشاء مخطط بياني Graph للعملية التي تحتوي جميع الكائنات Objects التي تكون قابلة للوصول من قبل جداول المؤشرات Roots.
بعد أن ينته جامع النفايات Garbage Collector من تشكيل المخطط البياني Graph يقوم بعملية اختبار لهذا البيان Graph فيقوم بعملية تحديد للكائنات Objects التي تحتل مكان في الكومة المدارة Managed Heap ولكن هذه الكائنات Objects غير مستخدمة من قبل التطبيق ,يعتبر جامع النفايات Garbage Collector أن جميع الكائنات Objects التي لا تستخدم من قبل التطبيق بأنها كائنات ملغية Null Objects فيقوم باستخدام أحد وظائف الكائن المستخدم التي تقوم بنسخ جميع محتويات الذاكرة المتعلقة بهذا الكائن Memory-Copying Function لتنسخ أماكن الكائنات Objects الغير مستخدمة ويقوم بعملية تعديل لمؤشرات Pointers هذه الكائنات Objects في جدول مؤشرات التطبيق للمؤشرات الجديدة وبعد هذه العملية يقوم بتحرير الذاكرة التي خصصت لهذه الكائنات Objects. ومن ثم يضع مؤشر الكومة المدارة Managed Heap بعد الكائن Object الأخير القابل للوصول. ويطلق على هذه العملية عملية ضغط الذاكرة Memory Compaction وهذه العملية تعمل فقط إذا اكتشف جامع النفايات Garbage Collector بأن هناك عدد ملحوظ من الكائنات Objects الغير مستخدمة. فهذا يعني إذا كانت جميع الكائنات Objects الموجودة في الكومة المدارة Managed Heap مستخدمة فليست هناك حاجة لعملية ضغط الذاكرة Memory Compaction.
لتحسن الأداء، يخصص وقت التشغيل Runtime ذاكرة للكائنات Objects الكبيرة في كومات منفصلة Separate Heap. يحرر جامع النفايات Garbage Collector الذاكرة آليا للكائنات Objects الكبيرة. على أية حال، لتجنب عملية نسخ الكائنات Objects الكبيرة يجب على هذه الذاكرة أن لا تقوم باستدعاء جامع النفايات Garbage Collector كثيراً .
• مرحلة التوليد و الأداء - Generations and Performance
لتحسين أداء جامع النفايات Garbage Collector، تقسم الكومة المدارة Managed Heap في ثلاثة مراحل للتوليد: 0، 1, 2. إن خوارزمية Algorithm جامع نفايات Garbage Collector وقت التشغيل Runtime مستندة على بضعة تعميمات بُنية عليها صناعة تطبيقات الحاسب وقد اكتشف من قِبل التجريب أنه يمكن لهذه الخوارزميات Algorithm أن تعمل مع مخططات مجموعة النفايات Garbage Collector وهي:
أولاً: إن ضغط Compaction أقسام من الذاكرة لقسم الكومة المدارة Managed Heap أسرع من ضغط Compaction جميع الكومة المدارة Managed Heap.
ثانيا: الكائنات Objects الأحدث ستملك عمر Lifetimes أقصر والكائنات Objects الأقدم ستملك عمر Lifetimes أطول. وأخيراً، الكائنات Objects الأحدث تميل لأن يتعلق كلاهما بالآخر وتحاول وصول التطبيق إليهم بنفس الوقت.
يخزن جامع نفايات Garbage Collector وقت التشغيل Runtime الكائنات Objects الجديدة في مرحلة التوليد 0. الكائنات Objects التي أنشئت في وقت عمل التطبيق التي تبقى في مجموعات فهي قد تم ترقيتها وتخزينها في مرحلة التوليد 1 و 2. (عملية ترقية الكائن Objects ستشرح لاحقاً في هذه الفقرة). لأن عملية ضغط Compaction قسم من الكومة المدارة Managed Heap أسرع من ضغط Compaction كل الكومة Heap، هذا المخطط يسمح لجامع النفايات Garbage Collector أن يحرر الذاكرة في مرحلة توليد محدده بدلاً من تحرير الذاكرة لكل الكومة المدارة Managed Heap كل وقت تنجز فيه عملية جمع النفايات Garbage Collect.
في الواقع، ينجز جامع النفايات Garbage Collector عملية التجميع عندما تنتهي مرحلة التوليد 0 بالكامل. إذا حاول التطبيق إنشاء كائن Object عندما تنتهي مرحلة التوليد0 بالكامل، يكتشف جامع النفايات Garbage Collector بأنه لم يعد هناك مكان في فضاء العناوين Address Space في مرحلة التوليد 0 التي سوف تخصص للكائن Object الجديد الذي يحاول التطبيق إنشائه. ينجز جامع النفايات Garbage Collector عملية جمع النفايات Garbage Collect في محاولة لتحرير فضاء عنوان Address Space للكائن Object الجديد في مرحلة التوليد 0. يبدأ جامع النفايات Garbage Collector باختبار الكائنات Objects في مرحلة التوليد 0 بدلا من اختبار كل الكائنات Objects في الكومة المدارة Managed Heap. هذا الطريقة أكثر كفاءة، لأن الكائنات Objects الجديدة تميل إلى امتلاك عمر قصير، وهي تتوقع بأن العديد من الكائنات Objects التي أنشئت في مرحلة التوليد 0 لن تكون قيد الاستعمال بالتطبيق عندما تبدأ عملية تجميع النفايات Garbage Collect. بالإضافة، مجموعة مرحلة التوليد 0 هي الوحيدة غالباً التي تسترد قدراً كاف من الذاكرة لكي تسمح للتطبيق بالاستمرار بإنشاء كائنات Objects جديدة.
بعد أن ينهي جامع النفايات Garbage Collector مجموعة مرحلة التوليد 0, يقوم بضغط الذاكرة Memory Compaction للكائنات القابلة للوصول كما وضحت في الفقرة السابقة تحرير الذاكرة - Releasing Memory في هذا الموضوع. جامع النفايات Garbage Collector إذن يرقي هذه الكائنات Objects ويعتبر هذا القسم من الكومة المدار Managed Heap بمرحلة مرحلة التوليد 1. لأن الكائنات Objects التي تبقى في مجموعات تميل لأن تملك مدة بقاء أطول، و من المعقول أن ترقى هذه الكائنات Objects إلى مرحلة توليد أعلى. نتيجة لذلك، ليس من مهام جامع النفايات Garbage Collector أن يعيد اختبار هذه الكائنات Objects في مرحلة التوليد 1و 2 في كل وقت ينجز فيها مجموعة مرحلة التوليد 0.
بعد أن ينجز جامع النفايات Garbage Collector مجموعته الأولى للتوليد 0 ويرقي الكائنات Objects القابلة للوصول إلى مرحلة التوليد 1, يعتبر بقية الكومة المدار Managed Heap لمرحلة التوليد 0. يستمر بتخصيص ذاكرة للكائنات Objects الجديدة في مرحلة التوليد 0 حتى تمتلئ مرحلة التوليد 0 وقد أصبح هنا من الضروري أن ينجز مجموعة أخرى. على هذه النقطة، جامع النفايات Garbage Collector يحسن إلى أبعد قدر ممكن محرك التحديد سواء أكان من الضرورة أن تختبر الكائنات Objects في مراحل التوليد الأقدم أم لا. على سبيل المثال، إذا لم تتمكن مجموعة مرحلة التوليد 0 أن تسترد ذاكرة كافية للتطبيق لكي تكمل محاولتها بإنشاء كائن Object جديد بنجاح ، جامع النفايات Garbage Collector يمكن أن ينجز مجموعة مرحلة التوليد 1, بدل من مرحلة التوليد 0. وإذا كانت هذه المرحلة لا تسترد ذاكرة كافية أيضاً، يمكن لجامع النفايات Garbage Collector أن ينجز مجموعة مرحلة التوليد الأخرى وهكذا يستطيع أن ينجز أي من مجموعات مراحل التوليد 0, 1, 2. بعد كل مجموعة، جامع النفاياتGarbage Collector يضغط الكائنات Objects القابلة للوصول في مرحلة التوليد 0 وترقيهم إلى مرحلة التوليد 1. الكائنات Objects في مرحلة التوليد 1 التي تعيش في مجموعات ترقي إلى مرحلة التوليد 2. لأن جامع النفاياتGarbage Collector يدعم فقط ثلاثة مراحل توليد، الكائنات Objects في مرحلة التوليد 2 التي تعيش في مجموعات تبقى في مرحلة التوليد 2 حتى تصمم هذه المجموعات في المستقبل أن تكون مجموعة غير مستخدمة.
تحرير الذاكرة للمصادر الغير مدارة - Releasing Memory for Unmanaged Resources
إن أغلبية الكائنات Objects التي ينشئها تطبيقك يمكنك أن تعتمد على جامع النفايات Garbage Collector ليؤدي مهمة إدارة الذاكرة الضرورية آليا. على أية حال، المصادر الغير مدارة Unmanaged Resources تتطلب من تطبيقك تنظيف واضح لهذه المصادر. إن الأنواع الأكثر شيوعاً من المصدر الغير مدار Unmanaged Resources هي الكائنات Objects التي تكون أحد المصادر التي تقدمها أنظمة التشغيل، مثل مقابض الملفات File Handle، مقابض النوافذ Window Handle، أو ارتباط الشبكات Network Connection. وبرغم من أن جامع النفايات Garbage Collector قادر أن يتعقب عمر الكائنات المدارة Managed Objects التي غلفت المصدر الغير مداره Unmanaged Resources، ولكن ليس لجامع النفايات Garbage Collector أية معرفة عن كيفية تنظيف المصادر الغير مدارة Unmanaged Resources . عندما تنشأ كائن Object يغلف مصدر غير مدار Unmanaged Resources، يوصى جامع النفايات Garbage Collector بأن تزوده بشيفرة كي تقوم بعملية النظيف للمصادر الغير مدارة Unmanaged Resources ويوصي أيضاً بأن تضع هذه الشيفرة في وظيفة تطلق عليها اسم Dispose. بتزويد الكائن Object هذه الوظيفة، سيتمكن المستخدمين لكائنك Object أن يحرروا المصادر التي قام كائنك Object باستخدامها بشكل واضح عندما ينتهون من استخدام كائنك Object. عندما تستخدم كائن Object يغلف مصادر غير مداره Unmanaged Resources، أنت يجب أن تكون مدرك للوظيفة التي تقوم بتنظيف المصادر الغير مدارة Unmanaged Resources ويجب أن تكن مدرك أنك يجب أن تستدعي هذه الوظيفة التي أوصى جامع النفايات Garbage Collector بان تطلق عليها الاسم Dispose عند الضرورة. للمزيد من المعلومات حول تنظيف المصادر الغير مدار أنظر الفصل جامع النفايات Garbage Collector.
ليست هناك تعليقات:
إرسال تعليق