RFC-0132：FIDL 資料表大小限制

摘要

這個 RFC 將 FIDL 資料表的項目數上限設為 64 個。

另請參閱：

• RFC-0047：表格
• RFC-0116：為較稀疏的 FIDL 資料表提供線路格式支援

提振精神

傳送 FIDL 表格 (建構、編碼和解碼) 的使用者模式效能成本，取決於表格主體中設定的最大序號。這項行為對使用者來說並不明顯或直覺，如果濫用，可能會導致負面效應。這份 RFC 提出了限制，可在短期內防止嚴重行為，並可做為權宜之計，促使 FIDL 作者重新思考設計，並鼓勵 FIDL 團隊在 FIDL 作者開始執行限制時，提供更完善的長期解決方案。

相關人員

誰會受到這項 RFC 是否通過的影響？

主持人：pascallouis@google.com

審查者：pascallouis@google.com、yifeit@google.com、mkember@google.com

諮詢對象：ianloic@google.com、azaslavsky@google.com、abarth@google.com

社交化：不適用

設計

表格最多只能有 64 個序數。具體違規事項如下：

• 如果序號值超過 64，則 FIDL 編譯器必須發出錯誤。
• 接收的序數大於 64 時，繫結項不得發生錯誤。可能會忽略大於 64 的序數。

此外，如果第 64 個序數未保留，則必須包含另一個表格，做為確保訊息可繼續擴充的機制。具體來說，如果第 64 個序數未保留且指派為非表格類型，則 FIDL 編譯器必須發出錯誤。

實作

這需要變更 FIDL 編譯器以及每個 FIDL 繫結。

成效

本節的所有測量結果皆以奈秒為單位，並在搭載 Intel Core i5-7300U CPU @ 2.60GHz 的 NUC 上記錄。

以下是 LLCPP 測量結果，顯示單向通訊所需的總使用者模式時間 (建構 + 編碼 + 解碼)：

無論是只設定最後一個欄位，還是設定所有欄位，結果都非常接近線性，斜率分別為 14.7 ns/field 和 63.7 ns/field。也就是說，未設定或保留的欄位大約需要 14.7 毫秒，而已設定的欄位則需要 63.7 毫秒。

當最大序號為 64 時，上次欄位設定時間為 3234.1 毫秒，所有欄位設定時間為 6294.2 毫秒。

請注意，這些時間可能會隨著繫結導入方式的變更而變動。

下表顯示 Fuchsia 系統中，FIDL 表格定義中目前的最大非保留序數分布情形：

表格定義中的最高序數為 56，其次為 26。這個包含 56 個欄位的資料表有許多不必要標示為保留的欄位，可以重新結構化，以便建立更精簡的資料表。這表示目前的資料表在一段時間內通常不會達到 64 個序數的限制。

較小的分配

部分繫結 (例如 LLCPP) 會計算訊息所需的最大緩衝區大小，並使用這項資訊來分配大小。如果資料表的大小不再無限，在某些情況下，您可以縮減分配的大小，進而提升效能。

人體工學

這項 RFC 會讓使用 FIDL 變得更加困難，因為現在必須考量限制。

回溯相容性

這份 RFC 會中斷與含有 64 個以上項目的資料表的回溯相容性。

安全性考量

這不會造成任何安全性問題。

隱私權注意事項

這不會影響隱私權。

測試

GIDL 測試會驗證線路格式是否維持不變，以及超過 64 個項目的表格解碼功能是否繼續運作。單元測試會檢查編譯器層級的變更。

說明文件

我們需要更新 FIDL 語言說明文件，以指出這項限制。

缺點、替代方案和未知事項

為什麼限制為 64 個？

64 這個限制是任意設定，但我們選擇這個數字有幾個原因：

• 這比大多數用途所需的容量還要大。雖然會出現異常值，但可以使用其他結構來表示資料。如果限制為 32，就會更接近目前常用的資料表大小。

• 如果限制值大於 64，使用者可能會因為效能降低而感到意外。如果發現更高的上限更常被需要，我們仍有可能透過另一項 RFC 再次調高上限。

• 64 是 64 位元整數的位元數。這樣一來，繫結就能使用位元旗標示是否存在。同樣地，位元遮罩可用於找出序數，如同已遭拒絕的 RFC RFC-0016 所示。

大型表格的替代方案

您可以使用多種替代結構取代大型表格。集合運算子的向量就是這類選項之一，它與資料表一樣可擴充，但集合欄位數量沒有限制。它也提供一種表示法，可能更適合用於使用欄位不密集的情況。

稀疏表格版面配置

先前遭到拒絕的 RFC 探討了可讓資料表以較稀疏的形式呈現的其他版面配置：RFC-0116：支援較稀疏的 FIDL 資料表的線格格式

如果資料表使用較稀疏的表示法，則可能不需要設下大小限制。