盤點.NET JIT在Release下由回圈體優化所產生的不確定性Bug

盤點在Release下由回圈體優化所產生的不確定性Bug

在這篇文章中，我將介紹一些在測驗環境(DEBUG)下正常，但在生產環境(Release)下卻會出現的一些讓人難以捉摸的Bug，

如果你對開源技術感興趣，歡迎和我一起共同貢獻開源專案，請聯系QQ群：976304396

Debug和Release的區別

首先，Debug和Release是一種編譯常量，其決定了編譯器是否對能夠對代碼開啟優化功能，

在Release下，代碼將被編譯器進行優化，這份優化除了我們能夠在編譯后所了解的IL代碼的區別外，還包括JIT(運行時)在正式轉化為機器碼前所布置的優化內容，而最終都將以匯編的方式呈現出來.

IL代碼是一種規范，無論在哪種環境下生成代碼，都不會改變邏輯的差異，但最終生成的匯編碼卻會因為JIT的內部表現而有所不同，
因此，當出現了代碼最終執行效果和我們在腦海中所構建的邏輯效果所不同時，我們不應該以IL的角度來去思考，而是以匯編的角度來去查看到底是在哪塊有了分歧，

目錄

• 回圈變數優化
  • 性能差異
• 潛在的Bug
  • 回圈變數不變
  • stackalloc不清零

IL代碼無論在哪種環境都會始終表現C#代碼的原意，因此，下文的示例將不在描述IL的部分，只描述在debug和release下匯編碼的真正區別，

回圈變數優化

讓我們先從一份簡單的for回圈代碼開始看起：

int len = 10;
for (int i = 1; i < len; i++)
{
}

這是一個簡單的for回圈邏輯，在方法內都始終存在兩個區域變數i和len，c#代碼邏輯所表述的是，我們通過訪問i的地址處的值和len的地址處的值進行比較，然后根據比較中的結果來去進行跳轉回圈，而匯編碼所表述的邏輯也基本相同，但對區域變數i和len的解釋有所不同，

在Debug下，JIT將始終讀取i和len位置處的值去進行比較

L0023: mov dword ptr [ebp-8], 0xa  //assign len
L002a: mov dword ptr [ebp-0xc], 1  //assign i
...
L0036: mov eax, [ebp-0xc] 
L0039: inc eax //i++
L003a: mov [ebp-0xc], eax //update i
L003d: mov eax, [ebp-0xc]
L0040: cmp eax, [ebp-8]  //compare

而在Release下，JIT將i的變數始終存盤在暫存器中，對于len,則以常量代替.

L0003: mov eax, 1
L0008: inc eax
L0009: cmp eax, 0xa

Release較Debug的變化是：JIT知道在當前方法背景關系中，len是個區域變數，且始終不會改變，因此可以提升為常量，這樣當進行比較時，可以不用每次都進行訪問，i也是個區域變數，且每次增加固定的常量1，因此i也不需要在堆疊中存盤，可以直接保留在暫存器中，這樣不會有取址的開銷，

上述例子說明了，在一定的條件下，編譯器會對回圈體中進行比較的變數進行特殊的優化，通過避免在地址中取值，以提升回圈的效率，

注:由于CPU對指令執行的速度遠高于訪問記憶體的速度,因此相比較對記憶體進行訪問是一種開銷,在訪問性能中,暫存器>cpu快取行>主存.

性能差異

讓我們通過下面一個例子來看一下，使用暫存器和不使用暫存器來保存回圈變數所帶來的性能差異:

public void Test1()
{
    int count = 0;
    for (int i = 1; i < 1000; i++)
    {
        ref _Int32 r = ref Unsafe.As<int, _Int32>(ref i);
        count += r.int32;
    }
}
public void Test2()
{
    int count = 0;
    for (int i = 1; i < 1000; i++)
    {
        _Int32 r = Unsafe.As<int, _Int32>(ref i);
        count += r.int32;
    }
} 

請通過Benchmark來對Test1和Test2進行測驗，你會發現，兩個方法之間的性能差別非常大，Test2的性能要遠超Test1，

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.17763.1518 (1809/October2018Update/Redstone5)
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.402
  [Host]     : .NET Core 3.1.8 (CoreCLR 4.700.20.41105, CoreFX 4.700.20.41903), X64 RyuJIT
  DefaultJob : .NET Core 3.1.8 (CoreCLR 4.700.20.41105, CoreFX 4.700.20.41903), X64 RyuJIT

近乎相同的代碼,為什么會有如此的差異?
如果我們對其生成的匯編代碼進行查看的話，你會發現在Test1中，對變數i的訪問，將始終通過尋址來去查找:

L000b: mov dword ptr [ebp-4], 1
L0027: cmp dword ptr [ebp-4], 0x3e8
...
L0020: mov edx, [ebp-4]
L0023: inc edx
...
L0024: mov [ebp-4], edx
L0027: cmp dword ptr [ebp-4], 0x3e8

而在Test2中,則始終通過在暫存器中存盤的值直接獲取:

L000c: inc edx
L000d: cmp edx, 0x3e8

在Test2方法中，因為變數i沒有被造成污染，因此最終代碼等價于 count += i ， 而在Test1方法中， 因為ref關鍵字的影響,導致了該代碼破壞了jit對回圈變數的優化規則，最終無法使用暫存器來直接存盤變數i，產生了性能的差異，

因此，在往后對回圈體的編程中，若代碼主體不會改變回圈變數的值的話，那么盡量可以在回圈體中創建一個副本來去使用，這樣對性能可以有效的提升，

注：ref Unsafe.As<int, _Int32>(ref i) 等價于 (_Int32*)&i
Unsafe.As<int, _Int32>(ref i) 等價于 *(_Int32*)&i

潛在的Bug

介紹完通過將回圈變數直接存盤在暫存器中的方式所帶來的性能提升后，下面我將介紹因為這種jit優化的方式所帶來的潛在性Bug，

for和while是在語法上有所不同，但最終執行表現是相同的，因此，為了后面的例子中所展示的邏輯更直白，對于回圈的語法，我將使用do while來描述，

回圈變數不變

[Fact]
public void Test1()
{
    int i = 1;

    Task.Run(() => { i = int.MinValue; });

    do { }
    while (i > 0);
}

這段代碼的邏輯是這樣的:

1. 主執行緒將無限進行回圈,直到i<=0才結束.
2. 第二條執行緒將改變i的值以讓它小于等于0

按照正常邏輯來走，第二條執行緒一定會執行改變值的代碼，因此方法在運行后始侄訓終止(會因主執行緒跳出回圈的結束而結束).

但這個邏輯實際上只在Debug下是正常的，在Release下，該程式將永遠不會結束，不信, 你可以嘗試下.

注意，這里只是通過值型別舉例說明，平常的編程習慣更多的是參考型別，如下:

object var = new object();
Task.Run(() => { var = null; });
do { }
while (var != null);

為什么會出現這樣的情況?

c#中寫是易失性寫，讀是非易失性讀，在本文中可以理解為，c#會對物件讀取做一定的優化，

在第二段中，我已經舉例介紹了這種優化，這取決于JIT是否能跟蹤到代碼對變數i的更改，若JIT通過中間形式決議后能夠跟蹤到對回圈變數的修改，則對回圈變數將不會使用暫存器來進行優化，

下面上述例子在DEBUG下的匯編，可以看到，最終對i的比較和賦值的是同一個地址：

L007e: cmp dword ptr [eax+4], 0  
mov dword ptr [eax+4], 0x80000000 

下面上述例子在Release下的匯編，可以看到，最終對i的比較和賦值不是同一個地址：

L0037: mov eax, [esi+4] 
L003a: test eax, eax 
mov dword ptr [ecx+4], 0x80000000 

在本例中，因為JIT在沒能跟蹤到委托中的回圈變數，最終取i的地址和在委托的閉包中設定的i的地址不是同一個位置，因此會產生無限輪訓，

解決方法也很簡單, 可以通過 Volatile.Read(ref i) 的方式來去閱讀它，這樣，編譯器將只是把i變數保留在eax中，且每次訪問都將從新取址獲取它，

或者像下面這兩個例子一樣，讓JIT能夠跟蹤到代碼對i的修改：

public void Test1()
{
    int i = 1;

    Task.Run(() => { i = int.MinValue; });

    do { i++; }
    while (i > 0);
}

public void Test1()
{
    int i = 1;

    Task.Run(() => { i = int.MinValue; });

    do { Aux(ref i); }
    while (i > 0);
}
private void Aux(ref int var)
{
    var++;
}

stackalloc不清零

在我撰寫Bssom.Net(一個結構化的高性能二進制序列化器)時，曾碰見了一個Bug，同樣的代碼在Debug下進行單元測驗時是沒問題的，在Release下卻會發生錯誤，最后經過排查并通過官方的幫助已確定是一個JIT的內部Bug，在此把它分享出來，

運行如下示例

public void Test1()
{
   for (int i = 1; i >= 0; i--)
   {
       Console.WriteLine(Test(i));
   }
}

public byte Test(int i)
{
    byte* c = stackalloc byte[8];
    c[i] = 42;
    return c[1];
}

這個示例在Debug下輸出 42，0
但是在Release下卻輸出 42，42
這意味著在Release下的stackalloc沒有對堆疊記憶體進行清零，這可能會因為使用到了未清零的資料而導致錯誤的邏輯產生，

而之所以會出現這樣的情況，這是因為JIT會對小的stackalloc分配代碼(本例中是8個位元組)進行行內，我們可以在Release下看到Test1方法在回圈外只進行一次0初始化，而不是每次呼叫Test方法并在Test方法中進行重新分配，

xor eax, eax
mov[ebp - 0xc], eax
mov[ebp - 8], eax
mov[ebp - 4], eax
...
L001d: lea edx, [ebp-0xc]
L002b: jge short L001d

這種情況源自JIT內部對stackalloc行內的判斷邏輯不夠具體，這個bug目前已經被修復，將添加在未來.net版本中，

那么，在當下版本(示例是使用net core3.1版本)中，我們該如何避免這種情況的產生?我給出了幾個參考：

• 如果邏輯允許的話，盡可能的將stackalloc提出回圈外
• 使用同等寬度位元組進行初始化而不是stackalloc，如 long
• 使用Span去創建Stackalloc，且通過Span.Clear方法來手動清空.
• 為方法標記[MethodImpl(MethodImplOptions.NoInlining)]

當然，如果通過stackalloc分配的記憶體超出32位元組，則不必擔心會出現本例中的情況，因為目前來說，JIT不會行內stackalloc分配超出32位元組的方法，

其它

作者：小曾
出處：https://www.cnblogs.com/1996V/p/13909855.html 歡迎轉載，但請保留以上完整文章，在顯要地方顯示署名以及原文鏈接，
Net開源技術交流群 976304396 , 抖音賬號: 198152455

標籤：.NET技术

上一篇：.NET中常用的資料結構

下一篇：c#使用Aspose實作Word域套打