Garbage Collection and Memory Management in .NET

What is Garbage Collection in .NET Framework?

لما أي ابلكيشن dot net بيشتغل، بيتعمل objects كتير جدًا في الميموري. وفي وقت معين، ممكن التطبيق بتاعك ميكونش بيستخدم بعض الـ objects دي. هنا بيجي دور الـ Garbage Collector في .NET Framework، وهو عبارة عن روتين صغير، أو نقدر نقول إنه Background Process Thread بيشتغل بشكل دوري عشان يحاول يحدد إيه هي الـ objects اللي مش مستخدمة حاليًا من خلال التطبيق، وبعدين بيبدأ يحرر الذاكرة الخاصة بالـ objects دي ويفضيها.

إذن، الـ Garbage Collector هو ميزة مهمة بيقدمها الـ CLR عشان تساعدنا ننضف أو ندمر الـ managed objects غير المستخدمة. عملية تنظيف الـ objects دي بترجعلنا المساحة اللي كانت واخدها في الذاكرة عشان نقدر نستخدمها تاني.

الـ Garbage Collection (GC) في .NET Framework بيعتبر نظام إدارة الميموري تلقائي (Automatic Memory Management)بيساعدك تهندل حوار الميموري في تطبيقاتك. في لغات .NET، لما بنعمل object جديد باستخدام كلمة new، بيتم تخصيص مساحة ليه في الميموري تلقائيًا على الـ managed heap. فبالتالي، إنت مش محتاج تخصص أو تحرر الذاكرة بنفسك بشكل يدوي زي ما بتعمل في لغات تانية زي C أو C++.

ملحوظة: الـ Garbage Collector بيدمر بس الـ managed objects غير المستخدمة، لكنه مش بينضف الـ unmanaged objects.

Managed and Unmanaged Objects in .NET Framework

خلينا نفهم إيه هما الـ Managed objects والـ Unmanaged objects. لما بنعمل أي ملف EXE (سواء كان Console Application أو Windows Application) أو Web Application (زي ASP.NET MVC أو Web API)، التطبيقات دي بتشتغل بالكامل تحت سيطرة وتحكم الـ CLR (Common Language Runtime). ده معناه إن لو تطبيقاتك فيها objects غير مستخدمة، الـ CLR هينضفها تلقائيًا باستخدام الـ Garbage Collector.

لنفترض إنك استخدمت ملف EXE من طرف تالت (third-party) في تطبيقك، زي برنامج Skype، PowerPoint، أو Microsoft Excel. الـ EXEs دي مش معمولة بتكنولوجيا dot net، دي معمولة بلغات برمجة تانية زي C، C++، أو Java.

لما بتستخدم الـ EXEs دي في تطبيقك، هي مش بتشتغل تحت إدارة الـ CLR. حتى لو شغلتها جوه تطبيقات dot net، هي هتشتغل تحت بيئتها الخاصة بيها. يعني مثلاً، لو الـ EXE ده معمول بـ C أو C++، هيشتغل تحت الـ C أو C++ Runtime Environment.

• الـ Managed Code: هو الكود اللي بيشتغل تحت تحكم كامل من الـ CLR في .NET Framework. الـ CLR بيوفر كل المميزات بتاعته للـ managed code زي الـ Language Interoperability، الـ Automatic Memory Management، الـ Exception Handling، والـ Code Access Security.
• الـ Unmanaged Code: هو الكود اللي مش بيشتغل تحت تحكم الـ CLR، زي برامج Skype و Excel. وبالتالي، الـ CLR مش بيوفر أي ميزة من مميزاته للكود ده.

Managed Objects

• هي عبارة عن objects بتتعمل على الـ managed heap وبيتحكم فيها الـ Garbage Collector (GC) بتاع بيئة .NET.
• الـ GC هو المسؤول عن إدارة Memory بتاعتها تلقائيًا.
• أمثلة عليها: أي instance من class أو struct بتعمله باستخدام كلمة new في C# أو VB.NET، أو الـ objects الأساسية زي الـ arrays والـ strings.

Unmanaged Objects

• هي عبارة عن objects الذاكرة بتاعتها مش بتدار بواسطة الـ GC.
• دي في العادة بتكون objects بتتعمل بكود أصلي (native code)، زي استدعاءات الـ Windows API أو عن طريق استخدام لغات زي C أو C++.
• المبرمج هنا هو المسؤول عن حوار الميموري بتاعتها بنفسه باستخدام APIs معينة زي malloc و free في لغة C أو new و delete في لغة C++.
• أمثلة عليها: الـ file handles، اتصالات DB، والـ COM objects.

---

Garbage Collection Memory Generations

خلينا نفهم إيه هي أجيال الـ Garbage Collector وإزاي بتأثر على الأداء بتاعه. الـ GC متقسم لتلات أجيال: الـ Generation 0، الـ Generation 1، والـ Generation 2.

Understanding Generation 0, 1, and 2

لنفترض إن عندك تطبيق بسيط اسمه App1. بمجرد ما التطبيق ده يبدأ يشتغل، بيعمل 5 من الـ managed objects. في العادي، كل ما يتم إنشاء objects جديدة، بتتحط في “جردل” (Bucket) اسمه Generation 0.

graph TD
    subgraph Heap
        subgraph "Generation 0"
            direction LR
            O1(Object1)
            O2(Object2)
            O3(Object3)
            O4(Object4)
            O5(Object5)
        end
    end
    A[New Objects] --> O1

إحنا عارفين إن الـ Garbage Collector بيشتغل باستمرار في الخلفية عشان يشيك ويشوف لو فيه أي objects غير مستخدمة. لنفترض إن التطبيق بتاعنا مبقاش محتاج Object1 و Object2. الـ GC هيدمرهم ويرجع المساحة بتاعتهم للميموري من الـ Generation 0. لكن من ناحية تانية، التطبيق لسه محتاج باقي التلاتة objects. الـ GC مش هينضفهم، وبدلًا من كده هينقلهم للجيل اللي بعده وهو الـ Generation 1.

graph TD
    subgraph Heap
        subgraph "Generation 0"
            G0["Empty"]
        end
        subgraph "Generation 1"
            direction LR
            O3(Object3)
            O4(Object4)
            O5(Object5)
        end
    end

    X(🗑️ Garbage)
    O1[Object1] -- Destroyed --> X
    O2[Object2] -- Destroyed --> X

    subgraph Survivors
        direction LR
        S3(Object3)
        S4(Object4)
        S5(Object5)
    end

    S3 -- Promoted --> O3
    S4 -- Promoted --> O4
    S5 -- Promoted --> O5

لنفترض دلوقتي إن تطبيقك عمل اتنين objects جداد (Object6 و Object7). بما إنهم objects لسه جداد، هيتحطوا مباشرة في الـ Generation 0.

دلوقتي، الـ GC هيشتغل مرة تانية، وبيروح أول حاجة للـ Generation 0 ويشوف إيه الـ objects المستخدمة. لنفترض إن الاتنين الجداد مش مستخدمين، فهيمسحهم. بعدين يروح للـ Generation 1 ويشوف إيه اللي مش مستخدم هناك. لنفترض إن التطبيق لسه محتاج Object4 و Object5 لكن مبقاش محتاج Object3. الـ GC هيدمر Object3 وينقل Object4 و Object5 للجيل الأخير اللي هو Generation 2.

Why do we need Generations?

الأجيال دي بتحدد مدة بقاء الـ objects في الذاكرة. طيب ليه بنحتاج الأجيال دي أصلاً؟

التطبيقات الكبيرة ممكن تعمل آلاف من الـ objects. لو الـ GC فضل يشيك عليهم كلهم في كل مرة بيشتغل فيها، العملية دي هتبقى مرهقة جدًا وبطيئة. بحوار الأجيال دا، لو فيه object موجود في الـ Generation 2، ده معناه إن الـ GC هيزوره عدد مرات أقل بكتير، لأن الـ object اللي بيوصل للمرحلة دي يبقى متوقع جدًا إنه هيفضل عايش في الذاكرة لفترة أطول.

ببساطة، تقسيم الذاكرة لـ Generations 0, 1, 2 بيساعد جدًا في زيادة أداء وسرعة الـ Garbage Collector. كل ما كانت أغلب الـ objects بتخلص في الـ Gen 0، كل ما كان الأداء أحسن والذاكرة بتستخدم بشكل مثالي.

---

How does using a Destructor in a Class end up in a Double Garbage Collector Loop?

زي ما وضحنا قبل كده، الـ GC بينضف الـ managed code بس. لو عندك في مشروعك unmanaged code، لازم توفر طريقة تنضفه بيها بنفسك. والمكان المنطقي اللي ممكن تفكر تحط فيه كود التنضيف ده هو الـ destructor بتاع الـ class. لكن للأسف، فيه مشكلة كبيرة جدًا مرتبطة بالموضوع ده.

لما بتعرف destructor في الـ class بتاعك، الـ GC قبل ما يدمر الـ object ده، بيروح يسأل الـ class: هل عندك destructor؟ لو الإجابة أيوة، بينقل الـ object ده للجيل اللي بعده (next generation bucket). بمعنى تاني، مش بينضفه في ساعتها، حتى لو هو فعليًا مش مستخدم. الـ GC بيستنى الـ destructor يشتغل الأول، وبعدين في Loop اللي بعدها يروح ينضفه. بسبب اللفة دي، هتلاقي objects أكتر بتتراكم في الـ Generation 1 والـ Generation 2 بدل ما تتنضف في الـ Generation 0، وده بيأثر بشكل سلبي على الأداء واستهلاك الميموري.

Example using Destructor to Destroy the Unmanaged Resources

بص على الكود ده. ده نفس المثال اللي ممكن نكون اتكلمنا عنه، بس ضفنا destructors للـ classes عشان نشوف المشكلة:

using System;
 
namespace GarbageCollectionDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i <= 1000000; i++)
            {
                MyClass1 obj1 = new MyClass1();
                MyClass2 obj2 = new MyClass2();
                MyClass3 obj3 = new MyClass3();
            }
            Console.Read();
        }
    }
 
    public class MyClass1
    {
        ~MyClass1()
        {
            // Clean unmanaged resources here
        }
    }
    
    // Similar for MyClass2 and MyClass3...
}

لو شغلت المثال ده واستخدمت أداة زي .NET Memory Profiler، هتلاحظ بوضوح إن فيه objects كتير جدًا اتنقلت وبقت في الـ Generation 1 والـ Generation 2. وده معناه إنك مش بتستغل الذاكرة بتاعتك بالشكل الصح.

---

How to Overcome the above Problem?

المشكلة اللي اتكلمنا عنها دي بتتحل عن طريق استخدام (Pattern) اسمه الـ Dispose Pattern. عشان تطبق Pattern ده، الـ class بتاعك لازم يطبق الـ IDisposable interface، ويوفر (Implementation) للـ Dispose method. جوه الـ Dispose method دي، بتكتب الكود الخاص بتنظيف الـ unmanaged objects، وفي آخر الـ method بتستدعي دالة GC.SuppressFinalize(true). الدالة دي بتدي أمر وتبلغ الـ GC إنه يتجاهل الـ destructor خالص ويروح ينضف الـ objects دي على طول من غير ما يستنى.

بس خلي بالك، بعد ما تخلص استخدام الـ object، لازم تستدعي الـ Dispose method بنفسك جوه الكود عشان تتجنب مشكلة الـ double garbage collector loop.

Example using Dispose Pattern to Destroy the Unmanaged Object in C#

using System;
 
namespace GarbageCollectionDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i <= 1000000; i++)
            {
                MyClass1 obj1 = new MyClass1();
                obj1.Dispose();
                
                MyClass2 obj2 = new MyClass2();
                obj2.Dispose();
                
                MyClass3 obj3 = new MyClass3();
                obj3.Dispose();
            }
            Console.Read();
        }
    }
 
    public class MyClass1 : IDisposable
    {
        #region IDisposable Support
        private bool disposedValue = false; // Detect redundant calls
        
        protected virtual void Dispose(bool disposing)
        {
            if (!disposedValue)
            {
                if (disposing)
                {
                    // Clean managed objects
                }
                // Clean unmanaged objects
                disposedValue = true;
            }
        }
        
        ~MyClass1()
        {
            Dispose(false);
        }
        
        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }
        #endregion
    }
    // Similar implementation for MyClass2 and MyClass3
}

لو جربت تشغل المثال ده وتراقبه بالـ profiler، هتلاحظ إن معظم الـ objects هتفضل وتتنضف في الـ Generation 0، وده طبعًا بيحسن من أداء تطبيقك بشكل ملحوظ.

طيب هنا ممكن تسأل: ليه الـ destructor لسه موجود في الكود؟ السبب هو إنه بيكون موجود كنوع من أنواع الضمان (Safety net). لو أنت كـ Developer نسيت تنادي الـ Dispose method بإيدك، الـ destructor هيشتغل في الآخر وينضف الـ object، وده بيحميك من إن يحصل (Memory Leak).

---

Notes

Correction (تصحيح فني)

• دالة GC.SuppressFinalize: واحنا بننادي على GC.SuppressFinalize()، الميثود دي مش بتاخد قيمة Boolean، دي بتاخد الـ object reference، يعني بتتكتب بالشكل ده: GC.SuppressFinalize(this).
• دورة حياة الـ Destructor: اللي بيحصل إن الـ GC لما بيلاقي object ليه Finalizer (أو Destructor) ومبقاش مستخدم، بينقله لطابور اسمه F-Reachable Queue. وجوده في الطابور ده بيخليه يُعتبر (Alive) بالنسبة للـ GC الحالي، فبالتالي بينجو من عملية التنظيف الحالية وبيترقى تلقائيًا للجيل اللي بعده. بعدين بيجي Thread مخصص للـ Finalizer ينفذ كود التنضيف، وفي دورة الـ GC اللي بعدها بيتم مسحه أخيرًا.
• الـ Managed Heap والـ Stack: مهم نوضح إن الـ Garbage Collector بيشتغل أساسًا على الـ Managed Heap (المكان اللي بيتخزن فيه الـ Reference Types زي الـ Classes). أما الـ Value Types (زي الـ int و الـ structs) فغالباً بتتخزن على الـ Stack، والـ Stack بينضف نفسه بنفسه بمجرد ما الـ Method تخلص، فمش بيحتاج تدخل من الـ GC.
• ليه الـ Generation 0 سريع؟: الـ Gen 0 بيكون مساحته صغيرة وغالبًا بيكون موجود جوه الـ CPU Cache، فعملية تنظيفه بتكون سريعة جدًا ومش بتأثر على أداء التطبيق.

الـ .NET 10 جايب معاه تحسينات قوية جدًا تخص الـ Garbage Collector عشان يقلل الضغط عليه ويزود الأداء:

1. الـ Stack Allocation for Small Arrays: في .NET 10، الـ JIT بقى أذكى، وبيقدر يحلل الكود (Escape Analysis). لو لقى إنك عامل Array صغير (سواء Value Type أو Reference Type) ومش هيخرج بره حدود الـ Method اللي اتعمل فيها، بيحجزه على الـ Stack بدل الـ Heap. ده بيقلل عدد الـ objects اللي الـ GC محتاج يراقبها ويمسحها.
2. الـ DATAS (Dynamic Adaptation To Application Sizes): النظام ده بقى متفعل بشكل تلقائي في معظم الإعدادات، وده بيخلي الـ GC يضبط مساحات الذاكرة بشكل ديناميكي حسب احتياج التطبيق الفعلي، مما يقلل من استهلاك الذاكرة بشكل كبير.
3. تحسينات الـ Write-Barrier (خاصة لمعالجات Arm64): الـ Write-Barrier هو ميكانيزم بيستخدمه الـ GC عشان يتتبع لو object قديم (في جيل أكبر) شاور على object جديد. في .NET 10 تم تحسين الميكانيزم ده وتقليل الاعتماد عليه في بعض الحالات، وده أدى لتقليل وقت التوقف (Pause Times) أثناء عمل الـ GC بنسب بتوصل لـ 20%.