编译调试 .NET Core 5.0 Preview 并分析 Span 的实现原理
很久沒有寫過 .NET Core 相關的文章了，目前關店在家休息所以有些時間寫一篇新的????。這次的文章主要介紹如何在 Linux 上編譯調試最新的 .NET Core 5.0 Preview 與簡單分析 Span 的實現原理。微軟從 .NET Core 5.0 開始把 GIT 倉庫 coreclr 與 corefx 合并移動到了 runtime 倉庫，原有倉庫僅用于維護 .NET Core 3.x，你可以從以下地址查看最新的源代碼：
https://github.com/dotnet/runtime
為了方便重現，接下來的編譯調試會使用 docker 與 ubuntu 18.04 鏡像（盡管微軟提供了編譯專用的鏡像但并不適合調試分析），步驟會與之前的博客介紹的 1.1，書籍介紹的 2.1 有一些不同。
如果你覺得閱讀這篇文章有困難，可以參考我之前發布的 .NET Core 源代碼分析系列或者書籍《.NET Core 底層入門》，書籍的購買鏈接在文章最后。
編譯 .NET Core 5.0 Preview
本文編譯的版本是 0d607a757372e3ecc8e942141d7f586a98694e42
創建 docker 容器
執行以下命令即可創建一個 ubuntu 18.04 的 docker 容器，注意創建時需要使用 --privileged 參數，否則無法使用 lldb 或者 gdb 調試程序。
docker run -it --privileged ubuntu:18.04安裝 cmake
.NET Core 5.0 要求的 cmake 版本非常高，我們需要添加第三方源來安裝新版本的 cmake：
apt-get update apt-get install apt-transport-https ca-certificates gnupg software-properties-common wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | apt-key add - apt-add-repository 'deb https://apt.kitware.com/ubuntu/ bionic main' apt-get update安裝依賴的類庫與工具
這個步驟與之前版本的 .NET Core 相同：
apt-get install git wget locales locales-all vim apt-get install cmake llvm-3.9 clang-9 libunwind8 libunwind8-dev gettext libicu-dev liblttng-ust-dev libcurl4-openssl-dev libssl-dev libnuma-dev libkrb5-dev下載 .NET Core 源代碼并編譯
這個步驟也與之前的 .NET Core 相同，但因為 corefx 合并到了同一個倉庫中，執行以下步驟以后會同時編譯 corefx 的 dll 文件。注意這個步驟編譯的是 Debug 版本的運行時，方便后面的調試。
git clone https://github.com/dotnet/runtime cd runtime ./build.sh編譯完成后你可以在 artifacts 文件夾下找到編譯結果。
使用 .NET Core 5.0 Preview 執行 Hello World 程序
接下來我們會看如何使用自己編譯的 .NET Core 執行一個 Hello World 程序，.NET Core 5.0 會同時編譯出 dotnet 程序，我們可以使用它代替 corerun 來簡化運行步驟（不需要像以前的版本一樣手動復制 corefx 的 dll或者設置?CORE_ROOT?環境變量）。但因為 runtime 倉庫中不包括 sdk（sdk 在 sdk 倉庫中，這次懶得編譯），我們仍然需要另外安裝一個官方的 .NET Core 用于創建與編譯 Hello World 程序。
安裝官方的 .NET Core 3.1 SDK
wget -q https://packages.microsoft.com/config/ubuntu/19.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb dpkg -i packages-microsoft-prod.deb apt-get update apt-get install dotnet-sdk-3.1創建與編譯 Hello World 程序
mkdir /console cd /console dotnet new console dotnet build執行 Hello World 程序
因為使用了 .NET Core 3.1 的 SDK 編譯，我們還需要修改?程序名.runtimeconfig.json?中的運行時版本號，否則會出現版本號不一致而執行失敗的問題。
cd /console/bin/Debug/netcoreapp3.1 vi console.runtimeconfig.json需要修改兩處：
runtimeOptions.tfm?修改到?netcoreapp5.0
runtimeOptions.framework.version?修改到?5.0.0
修改完以后使用以下命令即可執行：
/runtime/artifacts/bin/testhost/netcoreapp5.0-Linux-Debug-x64/dotnet console.dll如果看到 Hello World 輸出就代表執行成功了。
調試 .NET Core 5.0 Preview
在 linux 上調試 .NET Core 一般使用 lldb (gdb 也可以但是沒有 SOS 插件支持)，SOS 插件的源代碼被搬到了 diagnostics 倉庫，所以我們還需要下載編譯這個倉庫的源代碼。
下載編譯 diagnostics 倉庫 (LLDB SOS 插件）
安裝 LLDB 與 LLDB 的開發文件：
apt-get install clang llvm lldb liblldb-3.9-dev下載編譯 diagnostics 倉庫：
git clone https://github.com/dotnet/diagnostics cd diagnostics ./build.sh編譯成功后你可以在?/diagnostics/artifacts/bin/Linux.x64.Debug/libsosplugin.so?找到 SOS 插件的 dll 文件。
使用 LLDB 調試 .NET Core
SOS 插件需要在執行到達 LoadLibraryExW 后才可以正常使用，使用 LLDB 的 -o 參數可以省略每次調試的時候都要做的準備工作：
cd /console/bin/Debug/netcoreapp3.1 lldb \-o "plugin load /diagnostics/artifacts/bin/Linux.x64.Debug/libsosplugin.so" \-o "process launch -s" \-o "process handle -s false SIGUSR1 SIGUSR2" \-o "b LoadLibraryExW" \-o "c" \-o "br del 1" \-o "sos Help" \/runtime/artifacts/bin/testhost/netcoreapp5.0-Linux-Debug-x64/dotnet console.dll執行以后會停在 LoadLibraryExW 并打印出 SOS 插件的幫助，接下來我們可以使用 SOS 插件給托管函數下斷點：
sos bpmd console.dll console.Program.Main然后使用 c 命令繼續執行程序，直到觸發斷點：
c到達斷點（JIT 編譯后的托管函數 Main）以后我們可以使用 SOS 插件打印這個托管函數編譯出來的匯編內容：
sos u $rip如果到此都沒有問題，那么接下來我們可以開始分析 Span 的實現原理了。
Span 與 Memory 簡介
Span 與 Memory 是微軟推出的，用于表示某段子內容的數據類型，它們的主要目的是為了減少內存分配與復制，例如取 "abcdefg" 的子字符串 "def"，傳統的方法 (Substring) 會分配一個長度為 3 的新字符串然后復制 "def" 過去，但 Span 與 Memory 可以直接使用原有的對象、子內容的開始位置與子內容的長度來表示一段子內容。在其他語言中也有類似 Span 與 Memory 的概念，例如 go 中的 slice，c 中指針與長度的結合 (例如?struct char_view { char* ptr, size_t size; })，與 c++ 中的?string_view?和?span?類型。
Span 與 Memory 的區別在于，Memory 是一個普通的類型，只保存?原有的對象、子內容的開始地址?與?子內容的長度，在內存中的表現可以參考下圖：
Memory 與很早就存在的 ArraySegment 實質上是一樣的，只是支持更多的類型，它們都不需要運行時或者編譯器的額外支持。
Span 則特殊很多，它保存了子內容的開始地址與長度（不保存原始對象的地址），使得它不需要計算開始地址并且允許指向托管對象以外的內容 (例如從 stackalloc 分配)。Span 在內存中的表現可以參考下圖：
Span 是一個?ref struct?類型 (這個類型可以說是專門為 Span 發明的），ref struct?只能保存在于棧上或者作為其他?ref struct?的成員 (最終來說只能保存在于棧上)，Span 只能存在于棧上主要有以下原因：
GC 處理 Span 對象的成本很高，所以不應該大范圍使用
Span 的讀寫是非原子的（兩個指針大小），如果允許在堆上就有可能被多個線程同時訪問
Span 可以由 stackalloc 生成，而 Span 自身并不會標記來源是托管對象還是?？臻g
因為 Span 需要運行時的額外支持，在 .NET Framework 與 Mono 上使用的 Span (從 Nuget 包安裝的) 實際上與 Memory 一樣，只有在 .Net Core 上才有以上的特性。
此外，因為部分對象的內容不可修改 (例如 string)，所以還有配套的?ReadOnlySpan?與?ReadOnlyMemory，它們除了在編譯器層面上限制修改以外，與原類型沒有什么區別。
調試分析 Span 的實現原理
接下來我們可以調試一個示例程序，簡單分析 Span 在運行時中的實現原理 (這次分析不涉及到 JIT 部分，雖然 JIT 部分很少)。
以下是示例程序的代碼：
using System;namespace console {class Program{static void Main(string[] args){Span<byte> span = new byte[10] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };span = span.Slice(5, 2);GC.Collect();Console.WriteLine(span.Length);}} }使用 LLDB 查看生成的匯編代碼
編譯示例程序與執行 LLDB 的命令請參考前面的內容，執行后可以使用以下命令給托管函數?Main?下斷點然后執行到斷點，并查看匯編代碼：
sos bpmd console.dll console.Program.Main c sos u $rip輸出如下：
(lldb) sos bpmd console.dll console.Program.Main Adding pending breakpoints... (lldb) c Process 6460 resuming JITTED console!console.Program.Main(System.String[]) Setting breakpoint: breakpoint set --address 0x00007FFF7BB352D0 [console.Program.Main(System.String[])] Process 6460 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 3.1frame #0: 0x00007fff7bb352d0 -> 0x7fff7bb352d0: pushq %rbp0x7fff7bb352d1: pushq %r130x7fff7bb352d3: subq $0x48, %rsp0x7fff7bb352d7: vzeroupper (lldb) sos u $rip Normal JIT generated code console.Program.Main(System.String[]) ilAddr is 00007FFFF18BB250 pImport is 00005576894771F0 Begin 00007FFF7BB352D0, size bc/console/Program.cs @ 9: >>> 00007fff7bb352d0 55 push rbp 00007fff7bb352d1 4155 push r13 00007fff7bb352d3 4883ec48 sub rsp, 0x48 00007fff7bb352d7 c5f877 vzeroupper 00007fff7bb352da 488d6c2450 lea rbp, [rsp + 0x50] 00007fff7bb352df 4c8bef mov r13, rdi 00007fff7bb352e2 488d7db0 lea rdi, [rbp - 0x50] 00007fff7bb352e6 b910000000 mov ecx, 0x10 00007fff7bb352eb 33c0 xor eax, eax 00007fff7bb352ed f3ab rep stosd dword ptr es:[rdi], eax 00007fff7bb352ef 498bfd mov rdi, r13 00007fff7bb352f2 48897df0 mov qword ptr [rbp - 0x10], rdi 00007fff7bb352f6 48bfe05fd87bff7f0000 movabs rdi, 0x7fff7bd85fe0 00007fff7bb35300 be0a000000 mov esi, 0xa 00007fff7bb35305 e8063fe079 call 0x7ffff5939210 (JitHelp: CORINFO_HELP_NEWARR_1_VC) 00007fff7bb3530a 488945d8 mov qword ptr [rbp - 0x28], rax 00007fff7bb3530e 48bf2894e07bff7f0000 movabs rdi, 0x7fff7be09428 00007fff7bb35318 e8b396e079 call 0x7ffff593e9d0 (JitHelp: CORINFO_HELP_FIELDDESC_TO_STUBRUNTIMEFIELD) 00007fff7bb3531d 488945d0 mov qword ptr [rbp - 0x30], rax 00007fff7bb35321 488b7dd8 mov rdi, qword ptr [rbp - 0x28] 00007fff7bb35325 488b75d0 mov rsi, qword ptr [rbp - 0x30] 00007fff7bb35329 e8829f307a call 0x7ffff5e3f2b0 (System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array, System.RuntimeFieldHandle), mdToken: 0000000006003730) 00007fff7bb3532e 488b7dd8 mov rdi, qword ptr [rbp - 0x28] 00007fff7bb35332 e8f9ecffff call 0x7fff7bb34030 (System.Span`1[[System.Byte, System.Private.CoreLib]].op_Implicit(Byte[]), mdToken: 00000000060012B1) 00007fff7bb35337 488945c0 mov qword ptr [rbp - 0x40], rax 00007fff7bb3533b 488955c8 mov qword ptr [rbp - 0x38], rdx 00007fff7bb3533f c5fa6f45c0 vmovdqu xmm0, xmmword ptr [rbp - 0x40] 00007fff7bb35344 c5fa7f45e0 vmovdqu xmmword ptr [rbp - 0x20], xmm0/console/Program.cs @ 10: 00007fff7bb35349 488d7de0 lea rdi, [rbp - 0x20] 00007fff7bb3534d be05000000 mov esi, 0x5 00007fff7bb35352 ba02000000 mov edx, 0x2 00007fff7bb35357 e844edffff call 0x7fff7bb340a0 (System.Span`1[[System.Byte, System.Private.CoreLib]].Slice(Int32, Int32), mdToken: 00000000060012BE) 00007fff7bb3535c 488945b0 mov qword ptr [rbp - 0x50], rax 00007fff7bb35360 488955b8 mov qword ptr [rbp - 0x48], rdx 00007fff7bb35364 c5fa6f45b0 vmovdqu xmm0, xmmword ptr [rbp - 0x50] 00007fff7bb35369 c5fa7f45e0 vmovdqu xmmword ptr [rbp - 0x20], xmm0/console/Program.cs @ 11: 00007fff7bb3536e e845b3ffff call 0x7fff7bb306b8 (System.GC.Collect(), mdToken: 0000000006000361)/console/Program.cs @ 12: 00007fff7bb35373 488d7de0 lea rdi, [rbp - 0x20] 00007fff7bb35377 e87cecffff call 0x7fff7bb33ff8 (System.Span`1[[System.Byte, System.Private.CoreLib]].get_Length(), mdToken: 00000000060012AC) 00007fff7bb3537c 8bf8 mov edi, eax 00007fff7bb3537e e8a5fcffff call 0x7fff7bb35028 (System.Console.WriteLine(Int32), mdToken: 0000000006000089)/console/Program.cs @ 13: 00007fff7bb35383 90 nop 00007fff7bb35384 488d65f8 lea rsp, [rbp - 0x8] 00007fff7bb35388 415d pop r13 00007fff7bb3538a 5d pop rbp 00007fff7bb3538b c3 ret我們可以看到 00007fff7bb35305 處的指令從托管堆分配了數組，00007fff7bb35329 處的指令初始化了數組內容，00007fff7bb35332 處的指令生成了第一個 span 對象，00007fff7bb35357 處的指令生成了第二個 span 對象。你可以從每一段匯編代碼上標記的文件名與行數找到對應的 C# 代碼。
分析棧上的內容
接下來我們會分析棧上的內容，包括數組的地址與 span 的內容等。
注意棧上會保存臨時變量和不使用的參數，這是因為之前的編譯沒有使用 Release 配置，你可以使用 Release 配置編譯再按這里的步驟試試有什么不同 (可能會更難理解一些)，使用 Release 配置時請關閉分層編譯，使用?export COMPlus_TieredCompilation=0?即可關閉。
首先我們來看看分配數組之前棧上 (當前幀) 有什么內容：
(lldb) b 0x00007fff7bb35305 Breakpoint 4: address = 0x00007fff7bb35305 # 分配數組的指令 (lldb) c Process 6460 resuming Process 6460 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 4.1frame #0: 0x00007fff7bb35305 -> 0x7fff7bb35305: callq 0x7ffff5939210 ; JIT_NewArr1VC_MP_FastPortable at jithelpers.cpp:25600x7fff7bb3530a: movq %rax, -0x28(%rbp)0x7fff7bb3530e: movabsq $0x7fff7be09428, %rdi ; imm = 0x7FFF7BE094280x7fff7bb35318: callq 0x7ffff593e9d0 ; JIT_GetRuntimeFieldStub at jithelpers.cpp:3635 (lldb) p/x $rsp (unsigned long) $2 = 0x00007fffffffd220 # 棧頂 (lldb) p/x $rbp (unsigned long) $3 = 0x00007fffffffd270 # 幀底 (lldb) p $rbp - $rsp (unsigned long) $4 = 80 # 當前幀大小 (lldb) memory read -s 1 -c 80 0x00007fffffffd220 0x7fffffffd220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ # 本地變量使用的空間 0x7fffffffd230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ # 本地變量使用的空間 0x7fffffffd240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ # 本地變量使用的空間 0x7fffffffd250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ # 本地變量使用的空間 0x7fffffffd260: b0 d5 00 54 ff 7f 00 00 00 00 00 00 00 00 00 00 ...T............ # rbp-0x10 是 args 參數，rbp-0x8 是上一幀 r13 的值接下來我們看看原始數組的地址與數組的內容，數組的本地變量 (臨時變量) 會保存到?$rbp-0x28，我們可以直接看這個地址中的內容。
(lldb) b 0x00007fff7bb3532e Breakpoint 5: address = 0x00007fff7bb3532e # 初始化數組后的指令 (lldb) c Process 6460 resuming Process 6460 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 5.1frame #0: 0x00007fff7bb3532e -> 0x7fff7bb3532e: movq -0x28(%rbp), %rdi0x7fff7bb35332: callq 0x7fff7bb340300x7fff7bb35337: movq %rax, -0x40(%rbp)0x7fff7bb3533b: movq %rdx, -0x38(%rbp) (lldb) p/x $rbp-0x28 (unsigned long) $6 = 0x00007fffffffd248 (lldb) memory read -s 1 -c 8 0x00007fffffffd248 0x7fffffffd248: 70 ed 00 54 ff 7f 00 00 p..T.... (lldb) dumpobj 7fff5400ed70 # SOS 插件提供的命令，用于輸出托管對象信息 Name: System.Byte[] MethodTable: 00007fff7bd85fe0 EEClass: 00007fff7bd85f30 Size: 34(0x22) bytes Array: Rank 1, Number of elements 10, Type Byte Content: .......... Fields: None (lldb) memory read -s 1 -c 26 0x7fff5400ed70 # 顯示數組對象的內容 0x7fff5400ed70: e0 5f d8 7b ff 7f 00 00 0a 00 00 00 00 00 00 00 ._.{............ # 0~8 是類型信息，8~16 是長度 0x7fff5400ed80: 01 02 03 04 05 06 07 08 09 0a .......... # 16~26 是數組內容接下來我們可以繼續執行，然后看看各個 Span 的內容：
(lldb) b 0x00007fff7bb3536e Breakpoint 6: address = 0x00007fff7bb3536e (lldb) c Process 6460 resuming Process 6460 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 6.1frame #0: 0x00007fff7bb3536e -> 0x7fff7bb3536e: callq 0x7fff7bb306b80x7fff7bb35373: leaq -0x20(%rbp), %rdi0x7fff7bb35377: callq 0x7fff7bb33ff80x7fff7bb3537c: movl %eax, %edi (lldb) memory read -s 1 -c 16 $rbp-0x40 0x7fffffffd230: 80 ed 00 54 ff 7f 00 00 0a 00 00 00 00 00 00 00 ...T............ # 第一個 span (臨時變量) 的開始地址與長度 (lldb) memory read -s 1 -c 16 $rbp-0x50 0x7fffffffd220: 85 ed 00 54 ff 7f 00 00 02 00 00 00 00 00 00 00 ...T............ # 第二個 span (臨時變量) 的開始地址與長度 (lldb) memory read -s 1 -c 16 $rbp-0x20 0x7fffffffd250: 85 ed 00 54 ff 7f 00 00 02 00 00 00 00 00 00 00 ...T............ # 本地變量 span 中的開始地址與長度從輸出中我們可以看到，第一個 span 的地址是 0x7fff5400ed80，這剛好是數組地址 0x7fff5400ed70 加上類型信息 (8) 與長度 (8) 以后的值，
也就是數組的內容，使用以下命令可以查看這個 span 指向的內容：
而第二個 span 的地址 0x7fff5400ed85 則是第一個 span 的地址加 5，并且長度為 2，使用以下命令可以查看這個 span 指向的內容：
(lldb) memory read -s 1 -c 2 0x7fff5400ed85 0x7fff5400ed85: 06 07 ..最后再看看棧上 (當前幀) 的內容：
(lldb) memory read -s 1 -c 80 0x00007fffffffd220 0x7fffffffd220: 85 ed 00 54 ff 7f 00 00 02 00 00 00 00 00 00 00 ...T............ # 本地變量 span 中的開始地址與長度 0x7fffffffd230: 80 ed 00 54 ff 7f 00 00 0a 00 00 00 00 00 00 00 ...T............ # 第一個 span (臨時變量) 的開始地址與長度 0x7fffffffd240: 98 ed 00 54 ff 7f 00 00 70 ed 00 54 ff 7f 00 00 ...T....p..T.... # 用于初始化數組的句柄，原始數組對象 (臨時變量) 0x7fffffffd250: 85 ed 00 54 ff 7f 00 00 02 00 00 00 00 00 00 00 ...T............ # 第二個 span (臨時變量) 的開始地址與長度 0x7fffffffd260: b0 d5 00 54 ff 7f 00 00 00 00 00 00 00 00 00 00 ...T............ # args 參數與上一幀 r13 的值查看托管函數對應 GC 信息中的各個 Slot
GC 信息是 .NET 運行時查找各個線程中托管函數的本地變量 (根對象) 時使用的信息，因為 GC 信息的編碼非常復雜，這里不會介紹如何解碼 GC 信息，
而是下斷點來看各個 Slot 的內容，從掃描到標記的調用鏈跟蹤 (backtrace) 如下：
GcInfoDecoder::EnumerateLiveSlots?是枚舉 Slot 的函數，GcInfoDecoder::ReportSlotToGC?是處理各個 Slot 的函數 (包括寄存器與棧)，GcInfoDecoder::ReportStackSlotToGC?是處理棧上 (引用類型或 ref 類型) 本地變量的函數。
我們可以在?這個位置?下斷點，然后查看解析出的各個 Slot 的信息：
(lldb) b gcinfodecoder.h:679 Breakpoint 8: where = libcoreclr.so`GcInfoDecoder::ReportSlotToGC(GcSlotDecoder&, unsigned int, REGDISPLAY*, bool, unsigned int, void (*)(void*, OBJECTREF*, unsigned int), void*) + 396 at gcinfodecoder.h:679, address = 0x00007ffff5a8836c (lldb) c Process 6460 resuming Process 6460 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 8.1frame #0: 0x00007ffff5a8836c libcoreclr.so`GcInfoDecoder::ReportSlotToGC(this=0x00007fffffffab28, slotDecoder=0x00007fffffffa8c0, slotIndex=0, pRD=0x00007fffffffb5b0, reportScratchSlots=true, inputFlags=0, pCallBack=(libcoreclr.so`GcEnumObject(void*, OBJECTREF*, unsigned int) at gcenv.ee.common.cpp:148), hCallBack=0x00007fffffffc700)(void*, OBJECTREF*, unsigned int), void*) at gcinfodecoder.h:679676 GcStackSlotBase spBase = pSlot->Slot.Stack.Base;677 if( reportScratchSlots || !IsScratchStackSlot(spOffset, spBase, pRD) )678 { -> 679 ReportStackSlotToGC(680 spOffset,681 spBase,682 pSlot->Flags, (lldb) p *pSlot (const GcSlotDesc) $12 = {Slot = {RegisterNumber = 4294967216Stack = (SpOffset = -80, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_INTERIOR }這個 Slot 代表?$rbp-80?($rbp-0x50) 處有引用類型或 ref 類型的本地變量，在前面的內容中我們已經知道?$rbp-0x50?儲存了第二個 span 對象，此外標志?GC_SLOT_INTERIOR?代表本地變量是對象中間的內存地址，而不是對象開頭（對象頭之后類型信息之前）的內存地址，這個標志會對 GC 標記與重定位對象產生很大的影響，微軟官方稱這樣的變量為?Interior Pointer。
繼續執行?c?與?p *pSlot?可以看到其他 Slot 的內容:
# $rbp-0x40, 即第一個 span 對象 (const GcSlotDesc) $13 = {Slot = {RegisterNumber = 4294967232Stack = (SpOffset = -64, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_INTERIOR } # $rbp-0x20, 即本地變量 span (const GcSlotDesc) $14 = {Slot = {RegisterNumber = 4294967264Stack = (SpOffset = -32, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_INTERIOR } # $rbp-0x30, 用于初始化數組的句柄 (const GcSlotDesc) $15 = {Slot = {RegisterNumber = 4294967248Stack = (SpOffset = -48, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_BASE } # $rbp-0x28, 原始數組對象 (const GcSlotDesc) $16 = {Slot = {RegisterNumber = 4294967256Stack = (SpOffset = -40, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_BASE } # $rbp-0x10, args 參數 (const GcSlotDesc) $17 = {Slot = {RegisterNumber = 4294967280Stack = (SpOffset = -16, Base = GC_FRAMEREG_REL)}Flags = GC_SLOT_BASE }標志?GC_SLOT_BASE?代表是普通的引用類型變量，指向對象的開始地址。
GC 掃描 Span 對象時的處理
接下來我們看看 GC 掃描 Span 對象時會做什么處理，盡管在上述例子中棧上保留了原始數組的地址，使用 Release 模式編譯時可能會出現不保留的情況，因此 .NET Core 的運行時支持根據對象中間的地址找到對象的開始地址 (在前幾年已經實現了)，重新運行程序并使用以下命令可以給標記對象存活的函數下斷點：
(lldb) b GCHeap::Promote Breakpoint 10: 2 locations.繼續執行到達斷點以后我們可以從?ppObject?得到標記對象地址的地址，這里的對象地址是第二個 span 對象中保存的開始地址，同時 flags 為 1 即?GC_CALL_INTERIOR?代表地址為對象中間的地址：
(lldb) b GCHeap::Promote Breakpoint 2: 2 locations. (lldb) c Process 6636 resuming Process 6636 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 2.1frame #0: 0x00007ffff5cb6dc3 libcoreclr.so`WKS::GCHeap::Promote(ppObject=0x00007fffffffd220, sc=0x00007fffffffc9b0, flags=1) at gc.cpp:3666936666 {36667 THREAD_NUMBER_FROM_CONTEXT;36668 #ifndef MULTIPLE_HEAPS -> 36669 const int thread = 0;36670 #endif //!MULTIPLE_HEAPS3667136672 uint8_t* o = (uint8_t*)*ppObject; (lldb) p/x *((long*)0x00007fffffffd220) (long) $0 = 0x00007fff5400ed85因為地址在對象中間，.NET Core 運行時需要先找到對象的開始地址才能標記對象存活 (標記存活的位是類型信息的最低位)，處理的代碼如下 (文件)：
#ifdef INTERIOR_POINTERS if (flags & GC_CALL_INTERIOR) {if ((o < hp->gc_low) || (o >= hp->gc_high)){return;}if ( (o = hp->find_object (o, hp->gc_low)) == 0){return;}} #endif //INTERIOR_POINTERS這里會先判斷地址是否在托管堆中 (如果是 stackalloc 生成的就不在），然后使用?gc_heap::find_object?來找到對象的開始地址，find_object?會先找到中間地址在 Brick 表對應的 Brick，然后找到該 Brick 對應范圍中的第一個托管對象，然后一個個掃描托管對象判斷地址屬于哪個托管對象，如果找到屬于的托管對象則使用該對象的開始地址，這是一個比較昂貴的操作。關于 Brick 表可以參考我之前寫的文章。
GC 重定位 Span 對象時的處理
接下來我們看看 GC 是怎么重定位 Span 對象的，先退出 LLDB 然后執行以下命令設置環境變量，這個環境變量可以強制每次 GC 的時候都啟用壓縮：
export COMPlus_gcForceCompact=1然后再執行 LLDB，給?GCHeap::Relocate?下斷點并執行到斷點：
(lldb) b GCHeap::Relocate Breakpoint 2: 2 locations. (lldb) c Process 6676 resuming Process 6676 stopped * thread #1, name = 'dotnet', stop reason = breakpoint 2.2frame #0: 0x00007ffff5cb4633 libcoreclr.so`WKS::GCHeap::Relocate(ppObject=0x00007fffffffd220, sc=0x00007fffffffb810, flags=1) at gc.cpp:3674136738 {36739 UNREFERENCED_PARAMETER(sc);36740 -> 36741 uint8_t* object = (uint8_t*)(Object*)(*ppObject);3674236743 THREAD_NUMBER_FROM_CONTEXT;36744 (lldb) p/x *((long*)0x00007fffffffd220) (long) $0 = 0x00007fff5400ed85同樣的，ppObject?是標記對象地址的地址，flags 為 1 即?GC_CALL_INTERIOR。具體處理代碼如下：
if ((flags & GC_CALL_INTERIOR) && gc_heap::settings.loh_compaction) {if (!((object >= hp->gc_low) && (object < hp->gc_high))){return;}if (gc_heap::loh_object_p (object)){pheader = hp->find_object (object, 0);if (pheader == 0){return;}ptrdiff_t ref_offset = object - pheader;hp->relocate_address(&pheader THREAD_NUMBER_ARG);*ppObject = (Object*)(pheader + ref_offset);return;} }{pheader = object;hp->relocate_address(&pheader THREAD_NUMBER_ARG);*ppObject = (Object*)pheader; }因為壓縮階段已經把對象內容移動了，重定位階段只需要修改地址到移動后的地址，不管地址是在對象開頭還是在對象中間，
對于小對象并不需要檢查標記是否帶有?GC_CALL_INTERIOR，直接找到對應的 Plug (relocate_address?會再次判斷地址是否在托管堆中)，
獲取 Plug 中保存的偏移值，然后讓地址減去該偏移值即可。而大對象則需要使用?find_object?來先定位對象的開始地址，以提升處理效率。
至此我們可以發現，因為 .NET 可以只根據 Span 找到原始對象并實現標記與重定位，所以 Span 原理上是可以保存在堆上的，但這需要犧牲一定性能支持線程安全與放棄 stackalloc (或者分離到另一個類型)，所以微軟沒有選擇這么做。
參考鏈接
https://github.com/dotnet/runtime
https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/linux-instructions.md
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/libraries/System.Private.CoreLib/src/System/Span.cs
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/libraries/System.Private.CoreLib/src/System/ReadOnlySpan.cs
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/libraries/System.Private.CoreLib/src/System/Memory.cs
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/libraries/System.Private.CoreLib/src/System/ReadOnlyMemory.cs
https://raw.githubusercontent.com/dotnet/runtime/0d607a757372e3ecc8e942141d7f586a98694e42/src/coreclr/src/gc/gc.cpp
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/coreclr/src/vm/gcinfodecoder.cpp
https://github.com/dotnet/runtime/blob/0d607a757372e3ecc8e942141d7f586a98694e42/src/coreclr/src/inc/gcinfodecoder.h
https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay
https://www.cnblogs.com/zkweb/p/6625049.html
寫在最后
在這里打個小廣告，我與檸檬????編寫的書籍《.NET Core 底層入門》在一月份出版了，出版社是北京航空航天大學出版社，你可以查看以下網站，找到內容介紹與購買鏈接：
https://netcoreimpl.github.io
或者直接訪問京東的購買鏈接
https://item.jd.com/12796746.html
最后傳播一下正能量，最近這段時間大家都不容易，我目前也沒有收入來源，但我們仍然需要擺正心態，相信祖國，支持政府一同抗擊疫情。
中國加油????????！武漢加油????????！國有戰，召必回，戰必勝????????！
總結
以上是生活随笔為你收集整理的编译调试 .NET Core 5.0 Preview 并分析 Span 的实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《ASP.NET Core 微服务实战》
- 下一篇： 利用obfuscar对.NET应用进行混