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

小曾看世界發表於2020-11-01
優化

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

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

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

Debug和Release的區別

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

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

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

目錄

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
Method Mean Error StdDev
Test1 2,261.6 ns 12.62 ns 11.80 ns
Test2 308.3 ns 3.43 ns 3.04 ns

近乎相同的程式碼,為什麼會有如此的差異?
如果我們對其生成的彙編程式碼進行檢視的話，你會發現在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

相關文章