‫تحلیل گریز و بهینه‌سازی تخصیص حافظه دلیگیت‌ها در NET 10.

تلاش برای افزایش کارایی و بهینه‌سازی عملکرد، همواره یکی از اهداف اصلی تیم توسعه‌دهنده پلتفرم دات‌نت بوده است. یکی از تکنیک‌های پیشرفته و کلیدی در این زمینه، تحلیل گریز (Escape Analysis) است که توسط کامپایلر درجا (Just-In-Time یا JIT) به کار گرفته می‌شود. با انتشار نسخه پیش‌نمایش 5 از NET 10.، این قابلیت هوشمند گسترش یافته و اکنون شامل بهینه‌سازی‌های قابل توجهی برای دلیگیت‌ها (Delegates) می‌شود. این پیشرفت، منجر به کاهش سربار تخصیص حافظه بر روی هیپ (Heap) و در نتیجه، بهبود عملکرد کلی برنامه‌ها می‌گردد.

پیش از ورود به جزئیات بهینه‌سازی دلیگیت‌ها، لازم است مفهوم تحلیل گریز را درک کنیم. تحلیل گریز، فرآیندی است که طی آن کامپایلر JIT تشخیص می‌دهد که آیا یک شیء ایجاد شده در داخل یک متد، از محدوده (Scope) آن متد "فرار" می‌کند یا خیر. فرار کردن یک شیء به این معناست که ارجاعی به آن به خارج از متد فعلی منتقل شود؛ برای مثال، از طریق بازگرداندن آن شیء به عنوان خروجی متد، یا ذخیره آن در یک فیلد استاتیک یا یک فیلد از شیء دیگری که عمر طولانی‌تری دارد.

اهمیت این تحلیل در تصمیم‌گیری برای محل تخصیص حافظه نهفته است. اگر کامپایلر با اطمینان تشخیص دهد که یک شیء هرگز از محدوده خود فرار نمی‌کند، می‌تواند آن را به جای هیپ، روی پشته (Stack) تخصیص دهد. تخصیص حافظه روی پشته بسیار سریع‌تر از هیپ است و مهم‌تر از آن، حافظه تخصیص داده شده به طور خودکار پس از خروج از متد آزاد می‌شود، بدون آنکه نیازی به مداخله زباله‌روب (Garbage Collector یا GC) باشد. این امر به کاهش فشار بر روی GC و کاهش وقفه‌های ناشی از آن (GC Pauses) منجر شده و عملکرد برنامه را بهبود می‌بخشد.

برای درک بهتر نوآوری اخیر، باید بدانیم که در پشت صحنه استفاده از دلیگیت‌ها و عبارات لامبدا (Lambda Expressions) چه اتفاقی می‌افتد. زمانی که شما یک دلیگیت تعریف می‌کنید که متغیرهای محلی (Local Variables) متد را به کار می‌گیرد، کامپایلر #C یک کلاس پنهان به نام کلوژر (Closure) یا کلاس نمایش (Display Class) تولید می‌کند (که معمولاً نامی شبیه به <>c__DisplayClass دارد). این کلاس، متغیرهای به دام افتاده (Captured Variables) را در قالب فیلدهای خود نگهداری می‌کند.

در زمان اجرا، دو تخصیص حافظه اصلی بر روی هیپ اتفاق می‌افتد:

به مثال زیر توجه کنید:

public static int Main()
{
    int local = 1;
    int[] arr = new int[100];
    var func = (int x) => x + local;
    int sum = 0;

    foreach (int num in arr)
    {
        sum += func(num);
    }

    return sum;
}

در NET 9.، اجرای این کد منجر به سه تخصیص حافظه اصلی بر روی هیپ می‌شد: یکی برای آرایه arr، یکی برای کلاس کلوژر که متغیر local را نگهداری می‌کند، و دیگری برای خود دلیگیت func. کدهای اسمبلی تولید شده توسط JIT در NET 9. با فراخوانی‌های متعدد CORINFO_HELP_NEWSFAST و CORINFO_HELP_NEWARR_1_VC، این تخصیص‌ها را تأیید می‌کنند. این فراخوانی‌ها نشانگر درخواست حافظه از هیپ هستند. حتی اگر دلیگیت func هرگز از متد Main خارج نشود، باز هم این سربار حافظه تحمیل می‌شد.

با انتشار نسخه پیش‌نمایش 5 از NET 10.، تحلیل گریز کامپایلر JIT هوشمندتر شده است. این کامپایلر اکنون می‌تواند فراخوانی دلیگیت‌ها را مدل‌سازی کرده و تشخیص دهد که آیا خود شیء دلیگیت (مثلاً Func) از محدوده فعلی خود فرار می‌کند یا خیر.

اگر تحلیل گریز به این نتیجه برسد که عمر شیء دلیگیت از عمر متد فعلی فراتر نمی‌رود، JIT آن را مستقیماً روی پشته تخصیص می‌دهد. این یک بهینه‌سازی چشمگیر است، زیرا یکی از تخصیص‌های پر تکرار روی هیپ را حذف می‌کند.

اگر به کد اسمبلی تولید شده برای همان مثال در NET 10. نگاه کنیم، متوجه یک تغییر کلیدی می‌شویم: یکی از فراخوانی‌های CORINFO_HELP_NEWSFAST که مربوط به تخصیص حافظه برای System.Func بود، حذف شده است. این نشان می‌دهد که شیء func دیگر روی هیپ ایجاد نمی‌شود. علاوه بر این، فراخوانی دلیگیت نیز به شکل مستقیم‌تری (call rax) انجام می‌شود که خود نشان‌دهنده حذف یک لایه واسط و بهینه‌تر شدن اجراست.

این بهینه‌سازی به طور خودکار و بدون نیاز به هیچ‌گونه تغییر در کد #C اعمال می‌شود و به توسعه‌دهندگان کمک می‌کند تا برنامه‌هایی سریع‌تر و با ردپای حافظه کمتر بنویسند، خصوصاً در سناریوهایی که از دلیگیت‌ها و عبارات لامبدا به وفور در حلقه‌ها یا مسیرهای پرتکرار کد (Hot Paths) استفاده می‌شود.

با وجود این پیشرفت بزرگ، هنوز یک تخصیص حافظه بر روی هیپ در مثال ما باقی مانده است: تخصیص مربوط به کلاس کلوژر (Program+<>c__DisplayClass0_0) که متغیر local را در خود جای داده است.

خبر خوب این است که تیم دات‌نت به این موضوع نیز آگاه است و قصد دارد در نسخه‌های آینده، قابلیت تحلیل گریز را برای پشتیبانی از تخصیص کلوژرها بر روی پشته نیز گسترش دهد. اگر این هدف محقق شود، در سناریوهایی مانند مثال فوق، تقریباً هیچ تخصیص حافظه‌ای بر روی هیپ رخ نخواهد داد که این یک دستاورد فوق‌العاده در زمینه بهینه‌سازی عملکرد محسوب می‌شود.

کدام‌یک از گزینه‌های زیر به بهترین شکل، شرط لازم برای تخصیص یک شیء دلیگیت بر روی پشته توسط کامپایلر JIT در NET 10. را توصیف می‌کند؟

الف) دلیگیت نباید هیچ متغیر محلی را به دام بیندازد (Capture).

ب) تحلیل گریز کامپایلر JIT تشخیص دهد که طول عمر دلیگیت به محدوده (Scope) فعلی آن محدود است.

ج) دلیگیت باید به عنوان static تعریف شده باشد.

د) این کار امکان‌پذیر نیست؛ دلیگیت‌ها همیشه بر روی هیپ تخصیص داده می‌شوند.

توسعه قابلیت تحلیل گریز برای در برگرفتن دلیگیت‌ها در NET 10.، گامی مهم در جهت تکامل مستمر پلتفرم دات‌نت است. این ویژگی با هوشمندی تمام، سربارهای پنهان مرتبط با یکی از پرکاربردترین ابزارهای زبان #C را کاهش می‌دهد. با حذف تخصیص‌های غیرضروری روی هیپ و انتقال آن‌ها به پشته، کامپایلر JIT به کاهش فشار بر روی زباله‌روب کمک کرده و به طور مستقیم به افزایش سرعت و پاسخگویی برنامه‌ها منجر می‌شود. توسعه‌دهندگان دات‌نت می‌توانند با اطمینان بیشتری از قدرت و انعطاف‌پذیری دلیگیت‌ها و عبارات لامبدا استفاده کنند، زیرا می‌دانند که پلتفرم به طور مداوم در حال بهینه‌سازی کدهای آن‌ها در پشت صحنه است.

گزینه ب: پاسخ صحیح است. شرط اصلی برای این بهینه‌سازی این است که تحلیل گریز کامپایلر JIT بتواند با اطمینان ثابت کند که شیء دلیگیت از محدوده‌ای که در آن تعریف شده است "فرار" نمی‌کند و در نتیجه می‌توان آن را با خیال راحت روی پشته تخصیص داد.