托管數建超大在 組 上構
BigSpan<T>是上数组一個麵向超大連續區域的棧上視圖:
public readonly ref struct BigSpan<T>{ internal readonly ref T _first; internal readonly nint _length;}它的基本形狀和 Span<T>一樣:一個起始引用加一個長度
。它的构建長度受 int大小限製
。最後隻調用這個分配器。托管作為數組元素的上数组值類型會占用 8 * 65535 = 524,280字節 。它會分配一個 ElementChunk1<T>[]
,构建
數據引用是托管通過把數組數據開頭重新解釋為 T得到的:
private static ref T GetDataReference(Array storage){ return ref Unsafe.As<byte, T>(ref MemoryMarshal.GetArrayDataReference(storage));}這就是為什麽連續存儲這個特性很重要 。則可以盡量接近直接數組訪問的上数组成本。避免每一次邏輯訪問都再走一次普通數組邊界檢查
。构建一個 FourElements<T>數組的托管每個物理元素,我們可以隻保留一組質數長度的上数组基礎塊類型,但能不能分配到需要的构建內存更重要
。而元素又內聯保存在這些塊裏,托管
nint offset = (nint)5_000_000_000L;Span<byte> window = buffer.AsSpan(offset,上数组 length: 4096);分配 API
最簡單的分配方式自然是調用構造函數 :
nint length = (nint)10_000_000_000L;BigArray<byte> buffer = new(length);不過 .NET 的數組也有顯式的 GC 分配輔助方法 ,或者為每一個長度準備一個 struct 要容易維護得多 。构建
在 64 位運行時上 ,托管
但這個限製針對的是數組的元素個數 ,反射以及大量現有代碼。公開 API 的輸入會先被驗證 ,對用戶來說,確定這個值之後,隻是每個元素變成了一小塊。
T。這裏當然說的是理論上限
,pinned適合需要把指針傳給非托管代碼的互操作場景;未初始化分配適合那種馬上會覆蓋整塊內存 、寫在最後
有了 BigArray<T>、集合
、而且它更適合非托管數據。尤其是在大分配的情況下。
BigSpan 和 BigMemory
隻有持有存儲的類型還不夠 。
BigSpan<T>並不指望讓所有現有 API 都接受超過 int.MaxValue個元素。
BigArray<byte> buffer = new((nint)Array.MaxLength + 1024);BigSpan<byte> span = buffer.AsBigSpan();span[Array.MaxLength] = 42;BigMemory<T>和 BigReadOnlyMemory<T>則是可以保存起來的視圖
。
在 .NET 裏,int[1024]存 4096 字節。但非常小
。隨機訪問模式也可能比小數組慢。
它隻保存兩個東西 :
internal readonly Array _storage;internal readonly nint _length;普通長度下,object這樣的引用類型就不適合這個方向。後麵的優化也談不上 。結果就是拋出 TypeLoadException,它仍然是一個托管數組對象,它們的 Span屬性會生成 BigSpan<T>或 BigReadOnlySpan<T>。
有了這些塊類型之後 ,以及是否固定。就可以容納四個邏輯上的 T 。準確地說是 127.998 TiB 。
sizeof(T) | chunkSize | 最壞情況多出的元素數 | 最壞情況多出的字節數 |
|---|---|---|---|
| 1 | 65535 | 65534 | 65534 B |
| 2 | 32767 | 32766 | 65532 B |
| 3 | 21845 | 21844 | 65532 B |
| 4 | 16383 | 16382 | 65528 B |
| 8 | 8191 | 8190 | 65520 B |
| 16 | 4095 | 4094 | 65504 B |
| 257 | 255 | 254 | 65278 B |
| 32768+ | 1 | 0 | 0 B |
可以看到最壞情況是邏輯長度剛好比塊大小的整數倍多 1,它可以讓一個 struct 表示固定數量的重複字段,BigArray<T>另外記錄真實的邏輯長度,底層仍然是一個托管數組,對於 object,
using System.Runtime.CompilerServices;[InlineArray(4)]struct FourBytes{ private byte _first;}它有一個很方便的地方:InlineArray也能用於引用類型。因為這件事會牽涉到運行時、BigSpan<T>和 BigMemory<T> ,
更進一步,但本質上仍然是一組數組
。然後實現使用引用偏移,仍然可能碰到非法組合。大小為 32 字節的類型可以使用 2,047。會在到達這條路徑之前失敗。再用一個類包起來;另一類是用交錯數組模擬一個更大的數組 。這兩種方案在某些場景下都能用,64 位係統上可以支持更大的範圍。那麽實現會分配 3 個物理塊
。BigArray<T>不需要像交錯數組包裝器那樣在每次訪問時都做除法和取餘;它隻是把一個托管數組對象視作一段更大的邏輯序列。
源代碼已開源在 GitHub,那麽四倍寬度的塊就能表示接近 80 億個邏輯元素
。但 ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<object>>>>就太大了,
8191分支並創建 ElementChunk8191<object>[];65535分支仍然存在給用於 byte這樣的類型使用,ToArray、即使真正想分配的是另一個塊形狀:AllocateArray<object>(42); // TypeLoadException: Array of type 'ElementChunk3`1[ElementChunk5`1[ElementChunk17`1[ElementChunk257`1[System.__Canon]]]]' from assembly 'ConsoleApp1' cannot be created because base value type is too large.Array AllocateArray<T>(int length){ if (length <= 8191) return new ElementChunk8191<T>[length]; else return new ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<T>>>>[length];}解決辦法是把真正的分配延遲到選中分支之後 。數組、和 BigArray<T>暴露出來的邏輯長度不同
。我們還會用 Span<T>、它會讓 GC 壓力更大,它可以防止未選中的塊數組類型被提前加載。其他長度都可以由這些基礎長度相乘得到
。由於 BigMemory<T>把底層托管數組保存在 _storage裏
,
public BigArray(nint length){ if ((nuint)length > (nuint)MaxLength) { ThrowHelpers.ThrowOutOfRange(nameof(length)); } if (length <= Array.MaxLength) { _storage = new ElementChunk1<T>[length]; } else { _storage = CreateBigArraySlow(length); } _length = length;}然後是索引器實現 。實現內部如果需要調用隻接受 Span<T>或 ReadOnlySpan<T>的 BCL API,如果 index
、塊結構體本身也可以組合。trim、就會碰到 GC、為了覆蓋 1 到 65,535 之間需要的塊長度 ,
通常不太建議隨意使用巨大的數組
。BigArray<T>本身可以保持得很小。它們的數組長度相同,
類型加載
現在假設 T是 64 位運行時上的 object
。想要直接放寬這個限製
,length 或 slice 超出合法範圍,數組數據區裏連續排列著塊結構體 ,最常見的一維、同時仍然讓這段存儲對 GC 可見 。
分配器來自一個針對塊長度的 switch。
這裏有一個重要的運行時類型加載限製:作為數組元素的值類型不能超過 65,535 字節。從零開始的數組是 SZArray,
最大長度則跟架構有關:
public static nint MaxLength => nint.Size == 4 ? Array.MaxLength : GetChunkLength() * (nint)Array.MaxLength;在 32 位運行時上 ,隻是在同一段數組數據區裏繼續往前走
。但它不會在 object路徑上被加載。如果一個方法裏引用了很多已經構造好的泛型數組類型,
這種做法會不會多分配一些沒有用到的空間?答案是會
,隻有和當前 Unsafe.SizeOf<T>()匹配的塊形狀會真正實例化 ,類型係統、再通過嵌套組合出其他長度
。而且分配用的輔助方法標記為 NoInlining
