| RFC-0059：向量、字串和陣列計數欄位中的保留位元 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這項 FTP 提案了幾項變更。向量、字串和陣列計數最多為 32 位元 (最大值為 232-1)。向量和字串計數欄位的最高 8 位元保留供繫結使用，用於記憶體內使用。電線必須填滿零。向量/字串計數字段的下 24 位元保留但未使用，且必須在連線時填入零。這些值無法由繫結使用，且可能會在日後的 FTP 中重新分配。 |
| 作者 | |
| 提交日期 (年-月-日) | 2020-03-16 |
| 審查日期 (年-月-日) | 2020-03-19 |
摘要
FIDL 向量 (和字串) 使用 64 位元計數欄位來表示編碼位元組數。這項 FTP 提案了幾項變更：
向量、字串和陣列計數最多為 32 位元 (最大值為 232-1)。
向量/字串計數字段的高位元 8 位元保留供繫結使用，用於記憶體內使用。電線必須填滿零。
向量/字串計數欄位的下 24 位元保留但未使用，且必須在連線上填入零。這些緩衝區無法由繫結使用，且可能會在日後的 FTP 中重新分配。
現有 64 位元計數欄位細目的視覺化呈現。
這會將向量、字串和陣列編碼大小上限從 18.45 艾位元組減少至 4.29 GB。
提振精神
LLCPP 繫結可讓物件就地編碼。為配合 LLCPP Builder 計畫，繫結現在會追蹤記憶體擁有權，簡化使用者建立物件的程序。具體來說，如果是向量，計數欄位的最高有效位元 (MSB) 會用於儲存擁有權資訊 (請參閱 vector_view.h)。這個位元會在線性化期間歸零，不會影響 FIDL 線路格式，但會防止 LLCPP 繫結將 MSB 用於計數值。
此舉是為了正式保留向量計數欄位的 MSB，供繫結使用，並將保留項目擴展至高位元 8 位元。
此外，繫結之間的最大計數也有些不一致。C++ 語言繫結和編譯器的各個部分都假設大小上限為 32 位元，但這個大小從未正式化，其他繫結也不會遵循。這項 FTP 會將向量/字串/陣列計數的大小上限正式設為 32 位元。
設計
64 位元向量 (和字串) 計數欄位的高位元 8 位元保留供繫結在記憶體中使用。透過連線傳送時，高位元 8 位元必須為零。
此外，接下來最上方的 24 位元 (位元 32-55) 為保留位元，繫結不得使用。此外，這些值在傳輸時也「必須」為零。
ABI 維持不變。
導入策略
每個繫結中的編碼和解碼邏輯都會更新，以驗證計數最多為 2^32-1。包括驗證高位元是否為零。如果在解碼期間違反這項限制，管道就會關閉。
人體工學
不適用
說明文件和範例
線路格式說明文件會更新，顯示保留位元。
回溯相容性
每個訊息的通道大小上限為 65536 個位元組 (16 位元)，因此 FIDL 編碼至管道訊息的系統部分不會有任何相容性問題。此外，程式碼的某些部分已假設向量/字串/陣列的數量上限為 232-1。
效能
對效能的影響微乎其微。實作異動僅限於額外的驗證檢查。
安全性
這應該不會造成任何安全風險。透過網路傳輸時，計數欄位的值會相同，且現在有額外的驗證檢查。
測試
每個繫結實作項目都負責測試其功能實作項目，包括測試驗證檢查。
缺點
完成這項 FTP 後，繫結就能將計數字段的上 8 位元用於任何用途。因此，要將這些位元回收用於新用途非常困難或不可能，因為這需要詳盡驗證每個繫結是否未使用這些位元，並可能將其從使用這些位元的位置遷移。
替代方案
向量擁有權資訊可以儲存在向量的指標欄位中，而不是計數欄位。
兩種可行的方式：
假設 >= 2 位元組對齊，並將擁有權布林值儲存在最低有效位元中。這種做法的問題在於，2 位元組對齊的假設難以強制執行，且通常不成立。程式碼庫中有些位置會從緩衝區的任意偏移讀取位元組。
使用位址空間的屬性指派未使用的位元，以保留記憶體擁有權資訊。問題在於無法保證記憶體空間中沒有未使用的位元。即使目前確實如此，但位址清除工具等工具會將資訊儲存在指標中的可用位元，這些工具與 LLCPP 之間可能會發生衝突。
此外，我們也討論了要為繫結保留的位元數，以及向量計數應有多大。如果向量數量較多，好處是難以預測未來需求，且其他系統會因任意大小限制而發生問題。不過，寫入大於 4.29 GB 的 FIDL 物件，在現實中很少有應用實例。在目前的 CPU 上，如果每個元素需要 1 個週期，編碼或解碼這麼多元素的物件會耗費超過 1 秒。大型原始陣列的編碼效率較高，因此一般應透過 VMO 等替代機制傳送，而非 FIDL。不過，為繫結保留過多位元可能會限制日後的使用情境。為求折衷，系統會保留 8 位元用於繫結、24 位元未使用，以及 32 位元用於計數。這樣一來，日後就能視需要進行變更。
先前技術和參考資料
不適用