RFC-0059：向量、字串和陣列計數欄位中的保留位元數

RFC-0059：向量、字串和陣列計數欄位中的保留位元
狀態已接受
區域
  • FIDL
說明

這項 FTP 提出了幾項變更。向量、字串和陣列的計數上限為 32 位元 (最大值 232-1)。向量和字串計數欄位的上 8 位元保留給繫結使用，以便在記憶體中使用。這些欄位必須在網路上填入零。接下來的 24 位元向量/字串計數欄位已保留，但未使用，且必須在網路上填入零。這些屬性無法由繫結項目使用，且可能會在日後的 FTP 中重新指派。
作者
提交日期 (年-月-日)2020-03-16
審查日期 (年-月-日)2020-03-19

編輯此 RFC

編輯 RFC 中繼資料

摘要

FIDL 向量 (和字串) 使用 64 位元計數欄位來表示已編碼位元組的數量。這項 FTP 提出了幾項異動：

  • 向量、字串和陣列的計數上限為 32 位元 (最大值 232-1)。

  • 向量/字串計數欄位的上 8 位元保留給記憶體內用途的繫結使用。這些欄位必須在網路上填入零。

  • 接下來的 24 位元向量/字串計數欄位是保留的，但未使用，且必須在網路上填入零。這些屬性無法由繫結項目使用，且可能會在日後的 FTP 中重新指派。

現有 64 位元計數欄位的細目視覺化呈現。

視覺化：32 位元用於計數，24 位元未使用，8 位元保留給繫結

這會將向量、字串和陣列的最大編碼大小從 18.45 EB 降至 4.29 GB。

提振精神

LLCPP 繫結可讓物件就地編碼。作為 LLCPP Builder 的一部分，現在的繫結會追蹤記憶體擁有權，以便為使用者簡化物件建立作業。特別是對於向量，計數欄位的最高有效位元 (MSB) 會用來儲存擁有權資訊 (請參閱 vector_view.h)。這個位元會在線性化期間歸零，不會影響 FIDL 線路格式，但會防止 LLCPP 繫結使用 MSB 做為計數值。

這麼做的目的，是為了讓繫結可使用向量計數器欄位的最高有效位元值保留位址，並將保留位址擴展至上位 8 位元。

此外，綁定項目之間的數量上限也有些許差異。C++ 語言繫結和編譯器的各個部分都假設最大大小為 32 位元，但這個大小從未正式化，也沒有其他繫結遵循。這個 FTP 將向量/字串/陣列計數的大小上限設為 32 位元。

設計

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/1，因此以這麼多元素的物件為例，編碼或解碼作業可能會花費超過一秒的時間。大型原始陣列可透過更有效率的方式進行編碼，因此通常應透過 VMOs 等其他機制傳送，而非透過 FIDL。不過，如果為繫結保留太多位元，可能會限制日後的用途。因此，我們將 8 位元保留給繫結，24 位元保留給未使用的值，而 32 位元則用於計數。這樣一來，日後可視需求進行變更。

既有技術與參考資料

無