.NET Runtime: CLR و JIT و GC

#عيلة .NET واختيار إصدار مدعومThe .NET family and support policy

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

الإصدارات الزوجية LTS بدعم 3 سنين، والفردية STS. سياسة STS اتوسّعت لـ 24 شهر من .NET 9. دعم .NET 8 و .NET 9 الاتنين بيخلص في نوفمبر 2026. لازم تتابع security patches كمان، مش بس الـ major version.

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

الأول بيوضح البيئة، والتاني أدوات البناء، والتالت runtimes المثبّتة. وجود SDK مش دليل إن سيرفر تاني عنده runtime مناسب.

#من C# لـ IL: CLR و CTS و CLSFrom C# to IL: CLR, CTS and CLS

علشان لغات مختلفة تشارك نفس libraries، محتاجين تمثيل موحّد للكود والأنواع. تخيّل IL تعليمات مشتركة، والـ runtime مدير التشغيل اللي بيحوّلها وينظم الموارد.

C# source
  -> Roslyn compiler
  -> Assembly: IL + metadata + manifest
  -> Runtime loader and type system
  -> JIT -> native instructions -> CPU
           GC, exceptions, threading and interop

• CLR: Common Language Runtime؛ اسم بيستخدم لوصف خدمات التشغيل. CoreCLR هو runtime أساسي في .NET الحديث، وفيه runtimes تانية حسب الـ workload.
• IL: Intermediate Language، مش تعليمات CPU مباشر. قابلية النقل بتعتمد كمان على libraries والـ native dependencies.
• CTS: Common Type System، قواعد تعريف الأنواع واستخدامها، زي value types و reference types.
• CLS: Common Language Specification، جزء مشترك من القواعد علشان public APIs تبقى قابلة للاستخدام من لغات .NET مختلفة. مثلاً unsigned types مش CLS-compliant.

[assembly: CLSCompliant(true)]
public static class InvoiceMath
{
    public static decimal AddTax(decimal total) => total * 1.14m;
}

الـ attribute بيطلب من compiler يفحص الـ public API حسب CLS؛ مش بيحوّل أي native dependency لحاجة cross-platform.

#أنواع JIT التاريخية ومعناها دلوقتيClassic JIT types and their modern equivalents

سؤال أنواع JIT تاريخي. جاوب بالأسماء التلاتة، وبعدها وضّح إن .NET الحديث مش بيعرضهم كتلات أوضاع تختار بينهم.

# Alternatives: publish the same project in different modes.
dotnet publish -c Release -r linux-x64 --self-contained false
dotnet publish -c Release -r linux-x64 -p:PublishReadyToRun=true
dotnet publish -c Release -r linux-x64 -p:PublishAot=true

الأول JIT عادي، والتاني R2R، والتالت Native AOT لو المشروع والـ dependencies متوافقين. ماتتعاملش مع NGen و Native AOT كأنهم نفس implementation.

#Tiered compilation و OSR و dynamic PGOTiered compilation, OSR and dynamic PGO

لو كل method اتعملها optimization تقيل قبل أول request، startup هيتأخر. ولو كل الكود فضل بسيط، throughput هيتأثر. الـ runtime بيوازن بينهم على مراحل.

1. Tier 0 بيوفر code سريع في التوليد؛ ReadyToRun ممكن يوفّر كود مبدئي جاهز.
2. الـ runtime بيراقب الاستخدام، ويعيد compile للـ hot methods في Tier 1 بتحسينات أقوى.
3. OSR، أو On-Stack Replacement، يقدر ينقل تنفيذ loop طويلة لكود محسّن وهي لسه شغالة.
4. Dynamic PGO بيجمع profile فعلي للـ branches والأنواع، ويستخدمه في inlining و guarded devirtualization. مفعّل افتراضياً من .NET 8 في الإعدادات المعتادة.

<PropertyGroup>
  <TieredCompilation>true</TieredCompilation>
  <TieredPGO>true</TieredPGO>
</PropertyGroup>

الأول بيسمح بالمراحل، والتاني بالـ profile. دول توضيح للإعدادات، مش توصية تضيفهم لكل مشروع. مفيش عدد calls ثابت مضمون للترقية. قيس startup لوحده و steady-state لوحده؛ benchmark من أول call بس ممكن يضللك.

#JIT ولا ReadyToRun ولا Native AOT؟Choosing JIT, ReadyToRun or Native AOT

اختيار طريقة النشر مرتبط بالـ cold starts، والـ memory، والـ compatibility، مش مسابقة مين أحدث.

#Stack و heap: مكان التخزين مش هو نوع القيمةStack and heap: storage versus semantics

فصل قيمة عن reference بيوضح النسخ؛ فصل stack عن heap بيوضح العمر والتخزين. الاتنين مش نفس السؤال. الـ stack زي مساحة شغل للـ thread، والـ heap مساحة objects أعمارها مش مرتبطة بنداء method واحد.

public struct Quantity { public int Value; }
public sealed class OrderLine { public Quantity Quantity; }

var line = new OrderLine();                 // (1)
line.Quantity.Value = 2;
var copy = line.Quantity;                   // (2)
copy.Value = 9;
object boxed = copy;                        // (3)
Console.WriteLine(line.Quantity.Value);     // 2

الـ references نفسها ممكن تبقى locals أو fields. Closures و async state machines ممكن تخلّي locals تعيش على heap. ماتختارش struct لمجرد اعتقاد إنه هيمنع أي allocation.

#GC: generations و LOH و background collectionGC generations, LOH and background collection

معظم temporary objects عمرها قصير، فجمع مساحة صغيرة كتير أرخص من فحص heap كله كل مرة. الـ GC بيبدأ من roots زي live locals، و static fields، و GC handles، ويتتبع الـ objects اللي لسه reachable.

• Small objects غالباً تبدأ في Gen0. الناجي ممكن يترقّى لـ Gen1 ثم Gen2. جمع Gen2 بيشمل الأجيال الأصغر.
• LOH للأجسام الكبيرة، عادةً 85,000 byte أو أكتر بحجم الـ object كله. بيتجمع مع Gen2، ومش بيتعمله compaction عادةً بشكل افتراضي.
• Background GC بيعمل جزء كبير من شغل Gen2 بالتوازي مع التطبيق؛ لسه فيه pauses ومراحل stop-the-world.
• الـ GC ممكن يعمل compact وينقل objects ويحدّث references. Pinning يمنع الحركة وممكن يزيد fragmentation.

byte[] small = new byte[1024];
byte[] large = new byte[100_000];
Console.WriteLine(GC.GetGeneration(small));  // typically 0 if no GC intervenes
Console.WriteLine(GC.GetGeneration(large));  // 2: LOH is collected with Gen2

الـ output الأول ممكن يتغير لو حصل collection. دي تجربة تعليمية، مش طريقة تختبر بيها business logic. ماتناديش GC.Collect() بعد كل request؛ عالج allocation rate والـ retention الأول.

#Server و Workstation GC و DATASServer GC, workstation GC and DATAS

خدمة عليها throughput عالي غير desktop محتاج استجابة سلسة. Workstation GC مناسب لبرامج تفاعلية وموارد محدودة. Server GC بيستخدم heaps و workers متعددة لتحقيق throughput، بس ممكن يحتاج memory أكتر.

DATAS، أو Dynamic Adaptation to Application Sizes، بيكيّف server GC مع حجم الداتا طويلة العمر وضغط الشغل، وبيغيّر عدد heaps حسب الاحتياج. اتقدّم في .NET 8 وبقى افتراضي للـ server GC من .NET 9. مش بديل عن memory limits ومش علاج لـ leak.

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>

الأول يطلب server GC، والتاني يسمح بالـ background collection. الـ host والبيئة بيأثروا على الوضع الفعلي؛ افحص GCSettings.IsServerGC. اختبر p95 و p99 latency والـ throughput والـ memory جوه نفس container limits. تفاصيل DATAS.

#Dispose و finalizers و SafeHandleDispose, finalizers and SafeHandle

GC بيسترجع managed memory لما ميبقاش فيه references، لكن file handle أو connection لازم يتقفل في وقت معروف. Dispose عقد للتنضيف الفوري؛ finalizer شبكة أمان غير مضمونة التوقيت ولا مضمونة وقت إغلاق الـ process.

// An inheritable owner of a managed disposable resource.
public class InvoiceFile : IDisposable
{
    private bool _disposed;
    private readonly FileStream _stream = File.OpenWrite("invoice.txt");

    public void Write(byte[] bytes)
    {
        ObjectDisposedException.ThrowIf(_disposed, this); // (1)
        _stream.Write(bytes);
    }

    public void Dispose()
    {
        Dispose(true);                                  // (2)
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;
        if (disposing) _stream.Dispose();                // (3)
        _disposed = true;
    }
}

using var file = new InvoiceFile();                      // (4)
file.Write([65, 66]);

لو class sealed وبيملك stream بس، Dispose بسيط كفاية. ماتضيفش finalizer لمجرد إنك بتعمل implement لـ IDisposable. لو ماسك raw native handle، فضّل SafeHandle وخلي ReleaseHandle مسؤول عن تحريره؛ الـ owner يقفل SafeHandle. في pattern قديم بيمسك raw resource بنفسه، finalizer ينادي Dispose(false) من غير لمس managed objects. استخدم IAsyncDisposable و await using لما التنضيف نفسه async.

#Memory leaks و assemblies و شكل النشرMemory leaks, assemblies and deployment units

Managed leak معناه objects لسه reachable بس التطبيق مش محتاجها: cache من غير حد، و event subscription من publisher طويل العمر، و timer، أو singleton ماسك scoped service. أما native memory leak ممكن يزوّد working set من غير زيادة managed heap.

1. راقب memory مع load ثابت وبعد هدوء الشغل، وميّز working set عن live managed heap.
2. استخدم counters للـ allocation rate، و Gen2، و LOH، وعدد collections.
3. خد gcdumps في توقيتين، وقارن الأنواع والـ retention paths. عند الحاجة استخدم dump و gcroot لتتبع الـ roots.
4. اصلح المالك والعمر، وبعدها أعد نفس السيناريو. جمع dump ممكن يوقف التطبيق مؤقتاً ويكشف بيانات حساسة.

# Install the diagnostic tools separately if needed.
dotnet-counters monitor --process-id 1234 --counters System.Runtime
dotnet-gcdump collect --process-id 1234 --output orders.gcdump
dotnet-gcdump report orders.gcdump

الأوامر بتراقب runtime، وتجمع managed heap graph، وتطبع report. الـ report النصي بداية؛ تحليل reference paths محتاج viewer مناسب. مرجع dotnet-gcdump.

Self-contained مش مرادف لـ single-file ولا Native AOT. P/Invoke بيوصل managed code بـ native APIs، ومحتاج اتفاق مضبوط على types و ownership.