| RFC-0059：向量、字串及陣列數量欄位中的保留位元數 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這個 FTP 提議進行一些變更。向量、字串和陣列的計數上限為 32 位元 (最大值 232-1)。而超過 8 位元的向量和字串計數欄位則保留給繫結使用，以供記憶體內使用。請務必將線材完全填滿。後續 24 位元的向量/字串數量欄位是保留狀態，但未使用，且必須在線上填入 0。繫結無法使用，且可能會在日後的 FTP 重新定位。 |
| 作者 | |
| 提交日期 (年/月) | 2020-03-16 |
| 審查日期 (年/月) | 2020-03-19 |
摘要
FIDL 向量 (和字串) 會使用 64 位元計數欄位來代表編碼的位元組數。這個 FTP 提議以下變更：
向量、字串和陣列的計數上限為 32 位元 (最大值 232-1)。
顯示在記憶體內用量最高的 8 位元向量/字串數量欄位，保留供繫結使用。請務必將線材完全填滿。
後續 24 位元的向量/字串數量欄位是保留狀態，但未使用，且必須在線上填入零。這些限制無法由繫結使用，且可能會在日後的 FTP 重新分配。
現有 64 位元計數欄位的細目視覺化資料。
這會將向量、字串和陣列編碼大小上限從 18.45 EB 減少至 4.29 GB。
提振精神
LLCPP 繫結啟用物件就地編碼。做為 LLCPPBuilder 開發的一環，繫結現在會追蹤記憶體擁有權，為使用者簡化物件建立流程。特別是向量方面，計數欄位最重要的位元 (MSB) 是用來儲存擁有權資訊 (請參閱 vector_view.h)。這個位元在線性化期間為零，不會影響 FIDL 傳輸格式，但會防止 LLCPP 繫結使用 MSB 計算計數值。
這麼做的目標是正式完成向量數量欄位的 MSB 保留，以便繫結使用，並將預留項目擴充至上限 8 位元。
另外，繫結之間的數量上限不一致。C++ 語言繫結和編譯器的各部分會假設大小上限為 32 位元，但這個大小從未正式化，且不會後面採用其他繫結。此 FTP 規定向量/字串/陣列計數的最大大小上限為 32 位元。
設計
超過 8 位元的 64 位元向量 (和字串) 數量欄位，將保留給繫結在記憶體內使用。透過電線傳送時，上層 8 位元必須為零。
此外，接下來的 24 位元 (位元 32-55) 會保留，且必須由繫結使用。此外，電線也必須是零。
ABI 維持不變。
導入策略
系統會更新每個繫結中的編碼和解碼邏輯，驗證計數不超過 2^32-1 個。包括驗證上位元是否為零。如果在解碼期間違反這項限制，系統就會關閉管道。
人體工學
無
說明文件與範例
線路格式說明文件會更新，顯示保留部分。
回溯相容性
通道的位元組大小上限為 65536 (16 位元)，因此 FIDL 編碼到管道訊息的部分系統不會有任何相容性問題。此外，部分程式碼部分已假設向量/字串/陣列的數量上限為 232-1。
效能
這類調整對效能的影響微乎其微。唯一的實作變更是額外驗證檢查。
安全性
這應該不會造成任何安全性風險。計數欄位的值和線路的值相同，現在有額外的驗證檢查。
測試
每個繫結實作都有責任測試這項功能的實作，包括測試驗證檢查。
缺點
在這個 FTP 之後，繫結將可使用計數欄位上 8 位元的上半部供任何用途。因此，要為了新目的而收回這些位元並不容易，您需要徹底驗證每個繫結都會留下未使用的位元，而可能使這些位元無法使用這些位元。
替代選項
向量擁有權資訊不必儲存在計數欄位中，而是儲存在向量指標欄位內。
兩種可能的方法：
假設 >= 2 位元組對齊，並將擁有權布林值儲存在最小的位元中。這種做法的問題是，假設使用 2 位元組對齊不容易強制執行，通常不是如此。程式碼集中有些地方，系統會從緩衝區中的任意偏移值讀取位元組。
使用位址空間的屬性指派未使用的位元，以保存記憶體擁有權資訊。這樣做的問題是，無法保證記憶體空間中未使用位元。即使現在確實如此，位址清理工具等工具通常會將資訊儲存在可用位元中，且這些工具與 LLCPP 之間可能會有衝突。
另外，也會探討要保留給繫結的位元數，以及向量數量應有多大。較大型的向量數量的引數，不易預測未來需求，其他系統在任意大小限制方面也發生問題。儘管如此，要編寫超過 4.29 gb 的 FIDL 物件其實很少。在目前的 CPU 上，為每個元素 1/cycle 不合理假設，使用這類元素對物件進行編碼或解碼會花費一秒才能完成。大型原始陣列能夠更有效率地編碼，通常則應使用 VMO 等替代機制 (而非 FIDL) 傳送。不過，如果為繫結預留過多位元，可能會限制日後的用途。幸好，系統會將 8 位元保留給繫結、24 位元未使用，以及 32 位元做為計數。這有助於因應日後的需求變化。
既有圖片與參考資料
無