計解析：Protobuf 的 C 內(nèi)核、Arena 內(nèi)存模型與 MiniTable / Reflection 雙層 Schema)
upb 設(shè)計解析Protobuf 的 C 內(nèi)核、Arena 內(nèi)存模型與 MiniTable / Reflection 雙層 Schema【免費下載鏈接】protobufProtocol Buffers - Googles data interchange format項目地址: https://gitcode.com/GitHub_Trending/pr/protobuf本文基于 docs/upb/design.md 梳理 upb 的完整設(shè)計思路upb 是 Protocol Buffers 倉庫中一個用 C 實現(xiàn)的 protobuf 內(nèi)核它不面向應(yīng)用直接開發(fā)而是作為“語言運行時之下的底座”被 Python、Rust、PHP、Ruby、Lua 等多種語言綁定所封裝。讀完本文你可以理解 upb 的設(shè)計目標與取舍、以upb_Arena為核心的內(nèi)存管理模型含 Fuse 與固定內(nèi)存塊的使用方式以及 MiniTable 與 Reflection 兩套 Schema 的加載、鏈接與適用場景從而掌握“把一個 C 內(nèi)核安全地包裝進托管語言運行時”的關(guān)鍵工程方法。什么是 upb一個刻意“不穩(wěn)定”的 C 內(nèi)核upbupb is a protobuf kernel written in C是一個快速且完全符合 protobuf 規(guī)范的實現(xiàn)暴露的是一套低級別 C API。它的定位非常明確upb 不設(shè)計給應(yīng)用直接調(diào)用——這個 C API 非常底層、不安全unsafe、并且變化頻繁。文檔明確指出upb 必須保留“隨時進行破壞性 API 變更”的自由以避免背上犧牲其兩大目標小代碼體積、高性能的技術(shù)債。設(shè)計目標與非目標原設(shè)計文檔將目標分為三類完整列出如下Goals目標完整的 protobuf 一致性Full protobuf conformance小的代碼體積Small code size快的性能Fast performance且不以代碼體積為代價易于被語言運行時封裝Easy to wrap in language runtimes易于適配不同的內(nèi)存管理方案引用計數(shù)、GC 等Non-Goals非目標穩(wěn)定的 APIStable API安全的 APISafe API面向應(yīng)用的順手 APIErgonomic APIParameters實現(xiàn)參數(shù)語言標準為 C99支持 32 位或 64 位 CPU假定 4 或 8 字節(jié)指針使用指針打標pointer tagging但避免其他實現(xiàn)定義行為implementation-defined behavior目標是絕不觸發(fā)未定義行為通過 ASAN、UBSAN 等測試保證無全局狀態(tài)、完全可重入fully re-entrant這套取舍可以從倉庫結(jié)構(gòu)中得到印證upb/目錄按職責拆分為base/、mem/、wire/、mini_table/、mini_descriptor/、reflection/、json/、text/、lex/等子模塊而語言封裝層則分布在 lua/upb.c、lua/upb.lua、rust/、php/、ruby/ 等處一致性則由 conformance/ 目錄下的測試套件含failure_list_python_upb.txt、failure_list_rust_upb.txt等針對 upb 后端的失敗列表持續(xù)驗證。Arenaupb 全部內(nèi)存管理的唯一模型upb 中所有內(nèi)存管理都通過 arena 完成統(tǒng)一使用upb_Arena類型。Arena 是malloc()/free()的替代方案能顯著降低內(nèi)存分配開銷Arena 從某個底層分配器通常是malloc()和free()獲取內(nèi)存塊對塊內(nèi)的分配請求用一個簡單的bump allocator按線性順序推進來滿足單個分配不能被單獨釋放只能整體upb_Arena_Free()釋放整個 arena連帶釋放其所有底層內(nèi)存塊。設(shè)計文檔中的標準用法示例upb_Arena* arena upb_Arena_New(); // Perform some allocations. int* x upb_Arena_Malloc(arena, sizeof(*x)); int* y upb_Arena_Malloc(arena, sizeof(*y)); // We cannot free x and y separately, we can only free the arena // as a whole. upb_Arena_Free(arena);這個“arena 參數(shù)”模式貫穿于所有 upb 數(shù)據(jù)結(jié)構(gòu) API任何會分配內(nèi)存的 upb 函數(shù)都接收一個upb_Arena*參數(shù)并用該 arena 而非malloc()/free()進行分配// upb API to create a message. UPB_API upb_Message* upb_Message_New(const upb_MiniTable* mini_table, upb_Arena* arena); void MakeMessage(const upb_MiniTable* mini_table) { upb_Arena* arena upb_Arena_New(); // This message is allocated on our arena. upb_Message* msg upb_Message_New(mini_table, arena); // We can free the arena whenever we want, but we cannot free the // message separately from the arena. upb_Arena_Free(arena); // msg is now deleted. }Arena 是 upb 性能故事的關(guān)鍵部分。解析一個大 protobuf payload 通常意味著快速創(chuàng)建一連串 message、數(shù)組repeated 字段和 map這些分配的速度對解析性能至關(guān)重要同樣重要的是整棵 message 樹的釋放也要盡可能快——arena 可以把這項開銷從O(n)降到O(lg n)。在倉庫中Arena 的完整實現(xiàn)在 upb/mem/arena.h 與upb/mem/arena.c。從源碼結(jié)構(gòu)看公開接口比設(shè)計文檔中還多了幾個面向包裝層的設(shè)施upb_Arena_IncRefFor()/upb_Arena_DecRefFor()見 upb/mem/arena.h#L71-L74允許按 owner 增刪引用upb_Arena_RefArena()見 upb/mem/arena.h#L108則創(chuàng)建from → to的單向生命周期引用保證to在from釋放前不會被釋放——這些正是“把 C arena 與 GC/引用計數(shù)體系對接”時需要的原語。upb_Arena_New()本身也只是內(nèi)聯(lián)包裝見 upb/mem/arena.h#L137-L143UPB_API_INLINE upb_Arena* upb_Arena_New(void) { return upb_Arena_Init(NULL, 0, upb_alloc_global); }避免懸垂指針單 Arena 與 Fuse 原語arena 上分配的對象通常會包含指向其他 arena 分配對象的指針例如一個upb_Message會持有指向其子 message 的指針而這些子 message 同樣分配在 arena 上。與unique_ptr這類獨占所有權(quán)方案不同arena 無法自動防止懸垂指針upb 的做法是提供工具幫助在高級內(nèi)存管理方案GC、引用計數(shù)、RAII、borrow checker與 arena 之間架橋。單 arena 場景是最簡單的如果一個 arena 內(nèi)所有對象同時被釋放那么 arena 內(nèi)部的懸垂指針就不可能發(fā)生。用戶仍需小心不要在 arena 釋放后繼續(xù)持有指向其內(nèi)存的指針但 arena 對象之間的懸垂指針從原理上被排除了。多 arena 場景才是難點如果存在從 arena A 指向 arena B 的指針如何保證它不會懸垂為此 upb 提供了名為fuse的原語// Fuses the lifetimes of a and b. None of the blocks from a or b // will be freed until both arenas are freed. UPB_API bool upb_Arena_Fuse(const upb_Arena* a, const upb_Arena* b);兩個 arena 被 fuse 后它們的生命周期被不可逆地綁定在兩個 arena 都被upb_Arena_Free()釋放之前任何一方都不會釋放自己的內(nèi)存塊于是兩個 arena 之間的懸垂指針不再可能發(fā)生。Fuse 的典型用途是把來自兩個不同 arena 的 message 合并例如把一個作為另一個的子 message 掛接。Fuse 是一個相對便宜的操作文檔給出量級約為 150ns且對參與 fuse 的 arena 數(shù)量幾乎是O(1)真實復(fù)雜度是逆 Ackermann 函數(shù)增長極其緩慢。需要注意的代價每個 arena 自身會占用一定的內(nèi)存所以“反復(fù)創(chuàng)建新 arena 并 fuse”并不免費但兩個 arena 的 fuse 本身 CPU 成本不高。在 upb/mem/arena.h#L59-L63 中可以看到該接口的當前聲明注釋還補充了一個設(shè)計文檔未強調(diào)的細節(jié)Fuse 操作本身是線程安全的可并發(fā)從多個線程調(diào)用。倉庫中docs/upb/arena_fusion.md也專門展開了 arena 融合的行為細節(jié)可作為延伸閱讀。初始內(nèi)存塊與自定義分配器無堆場景下使用 upbupb_Arena默認用malloc()/free()獲取和歸還底層塊但這個默認策略可以定制以適應(yīng)特定語言的需求。創(chuàng)建 arena 的最底層函數(shù)是// Creates an arena from the given initial block (if any -- n may be 0). // Additional blocks will be allocated from |alloc|. If |alloc| is NULL, // this is a fixed-size arena and cannot grow. UPB_API upb_Arena* upb_Arena_Init(void* mem, size_t n, upb_alloc* alloc);參數(shù)行為[mem, n]緩沖區(qū)作為初始塊initial block使用在所有底層分配函數(shù)被調(diào)用之前優(yōu)先滿足分配請求。注意upb_Arena結(jié)構(gòu)體本身若可能也會從初始塊中分配因此 arena 實際可用于分配的內(nèi)存會少于nalloc指定初始塊耗盡之后使用的自定義分配函數(shù)若傳入NULL作為分配函數(shù)則初始塊是 arena 中唯一的內(nèi)存來源——由此得到一個固定大小、不可增長的 arena這使 upb 即使在沒有堆的環(huán)境中也能運行。由此推出的重要推論upb_Arena_Malloc()是一個可能失敗的操作只要存在使用固定大小 arena 的可能upb_Message_New()等一切分配型操作都必須檢查失敗返回值。當前實現(xiàn)中該約束依然成立例如 upb/mem/arena.h#L49-L50 處的聲明保留了相同的三參數(shù)簽名另有一個演進細節(jié)實現(xiàn)層新增了upb_Arena_SetAllocCleanup()見 upb/mem/arena.h#L56-L57允許注冊一個在 arena 銷毀時執(zhí)行的清理函數(shù)這為封裝語言提供了掛載析構(gòu)邏輯的鉤子。Schemaupb 中幾乎所有操作的前提upb 中幾乎每個操作都要求你先擁有一個 schema。protobuf schema 是包含.proto文件中定義的所有 message、field、enum 等定義的數(shù)據(jù)結(jié)構(gòu)創(chuàng)建、解析、序列化或訪問 message 都必須有 schema。因此加載 schema 通常是使用 upb 時的第一步。為什么必須 schema-first設(shè)計文檔在此處有一個關(guān)于 protobuf 本質(zhì)的重要洞見這與 protobuf 線格式wire format本身有關(guān)。與 JSON 不同protobuf 無法以無 schema 的方式被解析或操作——因為二進制線格式不區(qū)分字符串和子 message一個對 schema 一無所知的通用解析器在原理上不可能實現(xiàn)。若未來某版線格式能區(qū)分這兩者才有可能存在 schema 無關(guān)的數(shù)據(jù)表示、解析器與序列化器。MiniTable 與 Reflection 對照upb 中有兩類表示 protobuf schema 的主要數(shù)據(jù)結(jié)構(gòu)MiniTables精簡緊湊的 schema 版本只包含解析/序列化二進制線格式所必需的信息Reflection包含.proto文件中的幾乎所有數(shù)據(jù)包括所有 message/field 等的原始名稱以及全部 options。兩者的主要區(qū)別繼承自原文檔的對照表MiniTablesReflectionContains包含字段編號和類型僅此而已.proto文件中的全部數(shù)據(jù)包括一切名稱Used to parse用途二進制格式JSON / TextFormatWire representation線格式載體MiniDescriptorDescriptorType names類型名upb_MiniTable、upb_MiniTableField、…upb_MessageDef、upb_FieldDef、…Registry注冊表upb_ExtensionRegistry用于擴展upb_DefPool選型原則如果只需要二進制線格式MiniTable 比完整 reflection 輕量得多如果需要解析 JSON 或 TextFormat、或需要訪問.proto中指定的 options則要用 Reflection。注意Reflection 內(nèi)部也包含 MiniTables——擁有 reflection 就同時擁有 MiniTable但反向不可行只加載了 MiniTable 的應(yīng)用無法得到對應(yīng)的 reflection。因此 upb 可以按需要裁剪成兩種形態(tài)只需 MiniTable 的那部分 upb 可視為“upb lite”——代碼體積和運行時內(nèi)存開銷都更小需要 reflection 的那部分視為“upb full”。判斷一個函數(shù)屬于哪一層只需看簽名里出現(xiàn)哪類類型出現(xiàn)upb_MiniTable/upb_MiniTableField等即該操作需要 MiniTable出現(xiàn)upb_MessageDef/upb_FieldDef等則需要 Reflection。MiniTable類型與二進制 APIMiniTable 由一族以upb_MiniTable命名的數(shù)據(jù)結(jié)構(gòu)表示upb_MiniTable代表 messageupb_MiniTableField、upb_MiniTableFile等。例如二進制解析入口// Parses the wire format data in the given buffer [buf, size] and writes it // to the message msg, which has the type mt. UPB_API upb_DecodeStatus upb_Decode(const char* buf, size_t size, upb_Message* msg, const upb_MiniTable* mt, const upb_ExtensionRegistry* extreg, int options, upb_Arena* arena);MiniTable 的三種加載方式來自 C 生成代碼upb 代碼生成器可以輸出.upb_minitable.c文件把 MiniTable 作為全局常量變量嵌入。主程序鏈接這些文件后MiniTable 會落在二進制的.rodata或.data.rel.ro段中運行時通過生成函數(shù)直接取到。在 Bazel 中可用upb_minitable_proto_library()規(guī)則完成生成與鏈接倉庫中對應(yīng)規(guī)則見 upb_generator/ 及 upb/bazel/ 目錄下的構(gòu)建邏輯。來自 MiniDescriptor用戶可以在運行時把 MiniDescriptor 構(gòu)建為 MiniTable。MiniDescriptor 是一種緊湊的、upb 專屬的線格式專門為此設(shè)計調(diào)用upb_MiniTable_Build()即可完成轉(zhuǎn)換。當前倉庫中該入口位于 upb/mini_descriptor/decode.h#L49-L52。來自 reflection如果已經(jīng)為某類型構(gòu)建了 reflection 數(shù)據(jù)結(jié)構(gòu)可通過upb_MessageDef_MiniTable()從upb_MessageDef取得對應(yīng)的upb_MiniTable。選擇準則設(shè)計文檔給出的實操指南已經(jīng)使用 reflection 的語言(3) 是顯而易見的首選回避 reflection 的語言在 (1) 與 (2) 之間若目標語言在給定平臺上參與標準二進制鏈接模型特別是通常用ld鏈接則用 (1)——即靜態(tài)加載static loading。靜態(tài)加載的優(yōu)點不需要任何運行時初始化啟動更快唯一例外是庫或二進制為位置無關(guān)代碼時ELF/Mach-O loader 可能做的指針重定位有利于跨語言共享 proto message——共享通常要求雙方使用完全相同的 MiniTable。靜態(tài)加載的主要缺點需要為每個.proto生成一個.upb.c文件并鏈接其傳遞閉包內(nèi)所有.upb.c。Bazel 下這相對容易其他構(gòu)建系統(tǒng)會麻煩一些。而 (2) 的動態(tài)加載優(yōu)點是不需要為每條消息鏈接 C 代碼。對許多語言工具鏈來說為每個 protobuf 文件或消息類型生成并鏈接自定義 C 代碼是沉重負擔MiniDescriptor 提供了一種無需跨越核心運行時之外的 FFI 邊界即可加載 MiniTable 的便捷途徑。動態(tài)加載的常見模式是把包含 MiniDescriptor 的字符串直接嵌入生成代碼。例如 Dart 生成代碼中對純原始字段 message 的樣子const desc r$(),*-#$%! /10; _accessor $pb.instance.registry.newMessageAccessor(desc);newMessageAccessor()的實現(xiàn)基本就是upb_MiniTable_Build()的包裝從 MiniDescriptor 構(gòu)建 MiniTable。在代碼生成器中MiniDescriptor 可由upb_MessageDef_MiniDescriptorEncode()API 獲得——用戶永遠不需要手工編碼 MiniDescriptor。MiniTable 的鏈接Linking動態(tài)構(gòu)建 MiniTable 時把每條 message 鏈接到其子 message 和 enum 是用戶的責任每條 message 的 message 類型字段和 closed enum 字段必須分別用upb_MiniTable_SetSubMessage()和upb_MiniTable_SetSubEnum()鏈接還有一個高層函數(shù)upb_MiniTable_Link()一次鏈接所有字段它與upb_MiniTable_GetSubList()是絕配——后者可以在代碼生成器中列出所有需要傳給upb_MiniTable_Link()的 message 和 enum。這些接口在倉庫中的位置與語義可參見 upb/mini_descriptor/link.hupb_MiniTable_GetSubList()獲取子依賴清單見 upb/mini_descriptor/link.h#L61upb_MiniTable_Link()執(zhí)行批量鏈接見 upb/mini_descriptor/link.h#L71。常見模式是把link()調(diào)用直接嵌入生成代碼例如 Dart 中構(gòu)建含子 message 與 enum 的 MiniTableconst desc r$3334; _accessor $pb.instance.registry.newMessageAccessor(desc); _accessor!.link( [ M2.$_accessor, M3.$_accessor, M4.$_accessor, ], [ E.$_accessor, ], );這里upb_MiniTable_GetSubList()在代碼生成器中發(fā)現(xiàn)了 3 個子 message 字段和 1 個子 enum 字段需要鏈接運行時這份 MiniTable 列表被傳入link()其內(nèi)部調(diào)用upb_MiniTable_Link()。兩點補充某些應(yīng)用可能作為樹搖tree shaking策略的一部分選擇推遲甚至跳過注冊某些子 message 類型使用靜態(tài) MiniTable 時不需要手工鏈接步驟因為鏈接由ld自動完成。MiniTable 與 closed enumMiniTable 主要承載 message、field 與 extension 的數(shù)據(jù)但對于 closed enum還需要一個upb_MiniTableEnum結(jié)構(gòu)保存該 enum 中定義的所有數(shù)值集合——原因是 closed enum 有一個麻煩的行為未知 enum 值會被放入 unknown field set。設(shè)計文檔判斷隨著 editions 的推進 closed enum 將逐步淡出upb_MiniTableEnum的相關(guān)性與開銷會隨之縮小直至消失。Reflectionupb full 的完整 schemaReflection 使用upb_MessageDef、upb_FieldDef等類型在運行時表示.proto文件的完整內(nèi)容。它們是 upb 中g(shù)oogle::protobuf::Descriptor、google::protobuf::FieldDescriptor等的直接對應(yīng)物。一個值得注意的命名約定upb 一律用Def替代 C 的DescriptorDef不到Descriptor長度的 1/3目的是節(jié)省 C 代碼中每行都要重復(fù)類型名的橫向空間例如upb_FieldDef_Name()對比upb_FieldDescriptor_Name()。這有意與 C 命名分叉是刻意的設(shè)計決策。需要 reflection 的操作示例// Parses JSON format into a message object, using reflection. UPB_API bool upb_JsonDecode(const char* buf, size_t size, upb_Message* msg, const upb_MessageDef* m, const upb_DefPool* symtab, int options, upb_Arena* arena, upb_Status* status);upb_DefPool是構(gòu)建并擁有一組 def 的頂層容器是 Cgoogle::protobuf::DescriptorPool的緊密對應(yīng)物用戶必須始終保證upb_DefPool的壽命長于它所擁有的任何 def 對象。倉庫中upb_DefPool的核心實現(xiàn)見 upb/reflection/def_pool.h 與upb/reflection/def_pool.c。Reflection 的兩種加載方式來自 C 生成代碼upb 代碼生成器可以創(chuàng)建foo.upbdefs.c文件嵌入 descriptor 并導(dǎo)出 C 函數(shù)把它們加入用戶提供的upb_DefPool來自 descriptor用戶可對運行時獲得的 descriptor 手工調(diào)用upb_DefPool_AddFile()見 upb/reflection/def_pool.h#L86隨后用upb_DefPool_FindMessageByName()見 upb/reflection/def_pool.h#L39-L40按名取出單個 message 的 def。與 MiniTable 不同從生成代碼加載 reflection 需要運行時初始化upb_MessageDef這類 reflection 數(shù)據(jù)結(jié)構(gòu)無法像upb_MiniTable那樣直接發(fā)射進.rodata。生成代碼是把序列化后的 descriptor proto 嵌入.rodata運行時再構(gòu)建為堆對象。由此不能簡單認為 (1) 只是 (2) 的便利包裝(1)確實鏈接了靜態(tài).upb.c中的 MiniTable 結(jié)構(gòu)而 (2) 會在堆上從頭構(gòu)建 MiniTable因此 (1) 在把 descriptor 加載進upb_DefPool時 CPU 和 RAM 略省更關(guān)鍵的是(1) 得到的 descriptor 能夠反射基于生成的.upb.cMiniTable 構(gòu)建的 message而 (2) 得到的 descriptor 擁有各不相同的 MiniTable無法反射使用生成 MiniTable 的 message。PHP、Ruby、Python 這類動態(tài)語言的常見模式是用 (2) 配合嵌入生成代碼的 descriptor。Python 生成代碼當前的樣子from google.protobuf import descriptor_pool as _descriptor_pool from google.protobuf.internal import builder as _builder _desc b\n\x1aprotoc_explorer/main.proto\x12\x03pkg DESCRIPTOR _descriptor_pool.Default().AddSerializedFile(_desc) _globals globals() _builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, _globals) _builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, google3.protoc_explorer.main_pb2, _globals)上面的AddSerializedFile()本質(zhì)上就是upb_DefPool_AddFile()的薄包裝。倉庫中 Python 實現(xiàn)python/ 目錄含descriptor_pool.c等 C 層代碼與 C 內(nèi)核的這條銜接路徑正是設(shè)計文檔所描述模式的落地。upb 在倉庫中的落地從內(nèi)核到語言綁定從源碼結(jié)構(gòu)看設(shè)計文檔中各概念在倉庫內(nèi)都有對應(yīng)落點可作為繼續(xù)深入的入口設(shè)計概念倉庫位置說明Arena 內(nèi)存模型upb/mem/arena.h、upb/mem/arena.cupb_Arena_Init/Free/Fuse/Malloc以及RefArena/IncRefFor等包裝層原語MiniTable 數(shù)據(jù)結(jié)構(gòu)upb/mini_table/message.h、field.h、enum.h、extension_registry.c等message/field/enum/擴展注冊表MiniDescriptor 構(gòu)建upb/mini_descriptor/decode.h、upb/mini_descriptor/link.hupb_MiniTable_Build、upb_MiniTable_Link等Reflectionupb/reflection/def_pool.h、def.h、field_def.c等upb_DefPool_AddFile、upb_MessageDef等代碼生成器bootstrap 編譯鏈upb_generator/minitable/、reflection/、stage0/、upb_generator/bootstrap_compiler.bzl生成.upb.c/.upbdefs.c用stage0引導(dǎo)自舉一致性驗證conformance/ 與 upb/conformance/各語言后端的 failure list 區(qū)分 cc/upb 實現(xiàn)語言綁定示例lua/upb.c、lua/upb.lua、rust/、python/“把 upb 封裝進語言運行時”的真實樣例其中 Lua 綁定lua/目錄中的upb.c/upb.lua/test_upb.lua是體量最小的完整封裝樣本適合想理解“如何把 C 內(nèi)核包進一門語言”的讀者作為起點閱讀。小結(jié)upb 的設(shè)計可以濃縮為三個關(guān)鍵決策三者共同服務(wù)于“可被任意語言運行時低成本封裝”這一總目標不追求 API 穩(wěn)定與安全換取小體積、高性能與自由演進的空間——upb 的定位是內(nèi)核而非 SDK一切分配經(jīng)由upb_Arena用 bump allocator 整體釋放換取分配/釋放速度用upb_Arena_Fuse和引用原語解決跨 arena 懸垂指針問題用upb_Arena_Init的初始塊 自定義分配器支持無堆環(huán)境雙層 SchemaMiniTableupb lite與 Reflectionupb full前者以字段號與類型的緊湊表示支撐二進制線格式并可靜態(tài)鏈接進.rodata后者承載完整.proto語義支撐 JSON/TextFormat 與 options 訪問且 Reflection 內(nèi)嵌 MiniTable、單向可降級、不可升級。對正在評估“為一種新語言實現(xiàn) protobuf 支持”的工程師而言upb 的設(shè)計文檔與上述源碼路徑給出了一條被 Python、Rust、PHP、Ruby、Lua、Dart 等綁定反復(fù)驗證過的路線在語言運行時與 C 內(nèi)核之間用 Arena 解決內(nèi)存歸屬用 MiniTable 或 MiniDescriptor 解決 schema 獲取把 FFI 面收斂到極小?！久赓M下載鏈接】protobufProtocol Buffers - Googles data interchange format項目地址: https://gitcode.com/GitHub_Trending/pr/protobuf創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 upb 設(shè)計解析：Protobuf 的 C 內(nèi)核、Arena 內(nèi)存模型與 MiniTable / Reflection 雙層 Schema
upb 設(shè)計解析Protobuf 的 C 內(nèi)核、Arena 內(nèi)存模型與 MiniTable / Reflection 雙層 Schema【免費下載鏈接】protobufProtocol Buffers - Googles data interchange format項目地址: https://gitcode.com/GitHub_Trending/pr/protobuf本文基于 docs/upb/design.md 梳理 upb 的完整設(shè)計思路upb 是 Protocol Buffers 倉庫中一個用 C 實現(xiàn)的 protobuf 內(nèi)核它不面向應(yīng)用直接開發(fā)而是作為“語言運行時之下的底座”被 Python、Rust、PHP、Ruby、Lua 等多種語言綁定所封裝。讀完本文你可以理解 upb 的設(shè)計目標與取舍、以upb_Arena為核心的內(nèi)存管理模型含 Fuse 與固定內(nèi)存塊的使用方式以及 MiniTable 與 Reflection 兩套 Schema 的加載、鏈接與適用場景從而掌握“把一個 C 內(nèi)核安全地包裝進托管語言運行時”的關(guān)鍵工程方法。什么是 upb一個刻意“不穩(wěn)定”的 C 內(nèi)核upbupb is a protobuf kernel written in C是一個快速且完全符合 protobuf 規(guī)范的實現(xiàn)暴露的是一套低級別 C API。它的定位非常明確upb 不設(shè)計給應(yīng)用直接調(diào)用——這個 C API 非常底層、不安全unsafe、并且變化頻繁。文檔明確指出upb 必須保留“隨時進行破壞性 API 變更”的自由以避免背上犧牲其兩大目標小代碼體積、高性能的技術(shù)債。設(shè)計目標與非目標原設(shè)計文檔將目標分為三類完整列出如下Goals目標完整的 protobuf 一致性Full protobuf conformance小的代碼體積Small code size快的性能Fast performance且不以代碼體積為代價易于被語言運行時封裝Easy to wrap in language runtimes易于適配不同的內(nèi)存管理方案引用計數(shù)、GC 等Non-Goals非目標穩(wěn)定的 APIStable API安全的 APISafe API面向應(yīng)用的順手 APIErgonomic APIParameters實現(xiàn)參數(shù)語言標準為 C99支持 32 位或 64 位 CPU假定 4 或 8 字節(jié)指針使用指針打標pointer tagging但避免其他實現(xiàn)定義行為implementation-defined behavior目標是絕不觸發(fā)未定義行為通過 ASAN、UBSAN 等測試保證無全局狀態(tài)、完全可重入fully re-entrant這套取舍可以從倉庫結(jié)構(gòu)中得到印證upb/目錄按職責拆分為base/、mem/、wire/、mini_table/、mini_descriptor/、reflection/、json/、text/、lex/等子模塊而語言封裝層則分布在 lua/upb.c、lua/upb.lua、rust/、php/、ruby/ 等處一致性則由 conformance/ 目錄下的測試套件含failure_list_python_upb.txt、failure_list_rust_upb.txt等針對 upb 后端的失敗列表持續(xù)驗證。Arenaupb 全部內(nèi)存管理的唯一模型upb 中所有內(nèi)存管理都通過 arena 完成統(tǒng)一使用upb_Arena類型。Arena 是malloc()/free()的替代方案能顯著降低內(nèi)存分配開銷Arena 從某個底層分配器通常是malloc()和free()獲取內(nèi)存塊對塊內(nèi)的分配請求用一個簡單的bump allocator按線性順序推進來滿足單個分配不能被單獨釋放只能整體upb_Arena_Free()釋放整個 arena連帶釋放其所有底層內(nèi)存塊。設(shè)計文檔中的標準用法示例upb_Arena* arena upb_Arena_New(); // Perform some allocations. int* x upb_Arena_Malloc(arena, sizeof(*x)); int* y upb_Arena_Malloc(arena, sizeof(*y)); // We cannot free x and y separately, we can only free the arena // as a whole. upb_Arena_Free(arena);這個“arena 參數(shù)”模式貫穿于所有 upb 數(shù)據(jù)結(jié)構(gòu) API任何會分配內(nèi)存的 upb 函數(shù)都接收一個upb_Arena*參數(shù)并用該 arena 而非malloc()/free()進行分配// upb API to create a message. UPB_API upb_Message* upb_Message_New(const upb_MiniTable* mini_table, upb_Arena* arena); void MakeMessage(const upb_MiniTable* mini_table) { upb_Arena* arena upb_Arena_New(); // This message is allocated on our arena. upb_Message* msg upb_Message_New(mini_table, arena); // We can free the arena whenever we want, but we cannot free the // message separately from the arena. upb_Arena_Free(arena); // msg is now deleted. }Arena 是 upb 性能故事的關(guān)鍵部分。解析一個大 protobuf payload 通常意味著快速創(chuàng)建一連串 message、數(shù)組repeated 字段和 map這些分配的速度對解析性能至關(guān)重要同樣重要的是整棵 message 樹的釋放也要盡可能快——arena 可以把這項開銷從O(n)降到O(lg n)。在倉庫中Arena 的完整實現(xiàn)在 upb/mem/arena.h 與upb/mem/arena.c。從源碼結(jié)構(gòu)看公開接口比設(shè)計文檔中還多了幾個面向包裝層的設(shè)施upb_Arena_IncRefFor()/upb_Arena_DecRefFor()見 upb/mem/arena.h#L71-L74允許按 owner 增刪引用upb_Arena_RefArena()見 upb/mem/arena.h#L108則創(chuàng)建from → to的單向生命周期引用保證to在from釋放前不會被釋放——這些正是“把 C arena 與 GC/引用計數(shù)體系對接”時需要的原語。upb_Arena_New()本身也只是內(nèi)聯(lián)包裝見 upb/mem/arena.h#L137-L143UPB_API_INLINE upb_Arena* upb_Arena_New(void) { return upb_Arena_Init(NULL, 0, upb_alloc_global); }避免懸垂指針單 Arena 與 Fuse 原語arena 上分配的對象通常會包含指向其他 arena 分配對象的指針例如一個upb_Message會持有指向其子 message 的指針而這些子 message 同樣分配在 arena 上。與unique_ptr這類獨占所有權(quán)方案不同arena 無法自動防止懸垂指針upb 的做法是提供工具幫助在高級內(nèi)存管理方案GC、引用計數(shù)、RAII、borrow checker與 arena 之間架橋。單 arena 場景是最簡單的如果一個 arena 內(nèi)所有對象同時被釋放那么 arena 內(nèi)部的懸垂指針就不可能發(fā)生。用戶仍需小心不要在 arena 釋放后繼續(xù)持有指向其內(nèi)存的指針但 arena 對象之間的懸垂指針從原理上被排除了。多 arena 場景才是難點如果存在從 arena A 指向 arena B 的指針如何保證它不會懸垂為此 upb 提供了名為fuse的原語// Fuses the lifetimes of a and b. None of the blocks from a or b // will be freed until both arenas are freed. UPB_API bool upb_Arena_Fuse(const upb_Arena* a, const upb_Arena* b);兩個 arena 被 fuse 后它們的生命周期被不可逆地綁定在兩個 arena 都被upb_Arena_Free()釋放之前任何一方都不會釋放自己的內(nèi)存塊于是兩個 arena 之間的懸垂指針不再可能發(fā)生。Fuse 的典型用途是把來自兩個不同 arena 的 message 合并例如把一個作為另一個的子 message 掛接。Fuse 是一個相對便宜的操作文檔給出量級約為 150ns且對參與 fuse 的 arena 數(shù)量幾乎是O(1)真實復(fù)雜度是逆 Ackermann 函數(shù)增長極其緩慢。需要注意的代價每個 arena 自身會占用一定的內(nèi)存所以“反復(fù)創(chuàng)建新 arena 并 fuse”并不免費但兩個 arena 的 fuse 本身 CPU 成本不高。在 upb/mem/arena.h#L59-L63 中可以看到該接口的當前聲明注釋還補充了一個設(shè)計文檔未強調(diào)的細節(jié)Fuse 操作本身是線程安全的可并發(fā)從多個線程調(diào)用。倉庫中docs/upb/arena_fusion.md也專門展開了 arena 融合的行為細節(jié)可作為延伸閱讀。初始內(nèi)存塊與自定義分配器無堆場景下使用 upbupb_Arena默認用malloc()/free()獲取和歸還底層塊但這個默認策略可以定制以適應(yīng)特定語言的需求。創(chuàng)建 arena 的最底層函數(shù)是// Creates an arena from the given initial block (if any -- n may be 0). // Additional blocks will be allocated from |alloc|. If |alloc| is NULL, // this is a fixed-size arena and cannot grow. UPB_API upb_Arena* upb_Arena_Init(void* mem, size_t n, upb_alloc* alloc);參數(shù)行為[mem, n]緩沖區(qū)作為初始塊initial block使用在所有底層分配函數(shù)被調(diào)用之前優(yōu)先滿足分配請求。注意upb_Arena結(jié)構(gòu)體本身若可能也會從初始塊中分配因此 arena 實際可用于分配的內(nèi)存會少于nalloc指定初始塊耗盡之后使用的自定義分配函數(shù)若傳入NULL作為分配函數(shù)則初始塊是 arena 中唯一的內(nèi)存來源——由此得到一個固定大小、不可增長的 arena這使 upb 即使在沒有堆的環(huán)境中也能運行。由此推出的重要推論upb_Arena_Malloc()是一個可能失敗的操作只要存在使用固定大小 arena 的可能upb_Message_New()等一切分配型操作都必須檢查失敗返回值。當前實現(xiàn)中該約束依然成立例如 upb/mem/arena.h#L49-L50 處的聲明保留了相同的三參數(shù)簽名另有一個演進細節(jié)實現(xiàn)層新增了upb_Arena_SetAllocCleanup()見 upb/mem/arena.h#L56-L57允許注冊一個在 arena 銷毀時執(zhí)行的清理函數(shù)這為封裝語言提供了掛載析構(gòu)邏輯的鉤子。Schemaupb 中幾乎所有操作的前提upb 中幾乎每個操作都要求你先擁有一個 schema。protobuf schema 是包含.proto文件中定義的所有 message、field、enum 等定義的數(shù)據(jù)結(jié)構(gòu)創(chuàng)建、解析、序列化或訪問 message 都必須有 schema。因此加載 schema 通常是使用 upb 時的第一步。為什么必須 schema-first設(shè)計文檔在此處有一個關(guān)于 protobuf 本質(zhì)的重要洞見這與 protobuf 線格式wire format本身有關(guān)。與 JSON 不同protobuf 無法以無 schema 的方式被解析或操作——因為二進制線格式不區(qū)分字符串和子 message一個對 schema 一無所知的通用解析器在原理上不可能實現(xiàn)。若未來某版線格式能區(qū)分這兩者才有可能存在 schema 無關(guān)的數(shù)據(jù)表示、解析器與序列化器。MiniTable 與 Reflection 對照upb 中有兩類表示 protobuf schema 的主要數(shù)據(jù)結(jié)構(gòu)MiniTables精簡緊湊的 schema 版本只包含解析/序列化二進制線格式所必需的信息Reflection包含.proto文件中的幾乎所有數(shù)據(jù)包括所有 message/field 等的原始名稱以及全部 options。兩者的主要區(qū)別繼承自原文檔的對照表MiniTablesReflectionContains包含字段編號和類型僅此而已.proto文件中的全部數(shù)據(jù)包括一切名稱Used to parse用途二進制格式JSON / TextFormatWire representation線格式載體MiniDescriptorDescriptorType names類型名upb_MiniTable、upb_MiniTableField、…upb_MessageDef、upb_FieldDef、…Registry注冊表upb_ExtensionRegistry用于擴展upb_DefPool選型原則如果只需要二進制線格式MiniTable 比完整 reflection 輕量得多如果需要解析 JSON 或 TextFormat、或需要訪問.proto中指定的 options則要用 Reflection。注意Reflection 內(nèi)部也包含 MiniTables——擁有 reflection 就同時擁有 MiniTable但反向不可行只加載了 MiniTable 的應(yīng)用無法得到對應(yīng)的 reflection。因此 upb 可以按需要裁剪成兩種形態(tài)只需 MiniTable 的那部分 upb 可視為“upb lite”——代碼體積和運行時內(nèi)存開銷都更小需要 reflection 的那部分視為“upb full”。判斷一個函數(shù)屬于哪一層只需看簽名里出現(xiàn)哪類類型出現(xiàn)upb_MiniTable/upb_MiniTableField等即該操作需要 MiniTable出現(xiàn)upb_MessageDef/upb_FieldDef等則需要 Reflection。MiniTable類型與二進制 APIMiniTable 由一族以upb_MiniTable命名的數(shù)據(jù)結(jié)構(gòu)表示upb_MiniTable代表 messageupb_MiniTableField、upb_MiniTableFile等。例如二進制解析入口// Parses the wire format data in the given buffer [buf, size] and writes it // to the message msg, which has the type mt. UPB_API upb_DecodeStatus upb_Decode(const char* buf, size_t size, upb_Message* msg, const upb_MiniTable* mt, const upb_ExtensionRegistry* extreg, int options, upb_Arena* arena);MiniTable 的三種加載方式來自 C 生成代碼upb 代碼生成器可以輸出.upb_minitable.c文件把 MiniTable 作為全局常量變量嵌入。主程序鏈接這些文件后MiniTable 會落在二進制的.rodata或.data.rel.ro段中運行時通過生成函數(shù)直接取到。在 Bazel 中可用upb_minitable_proto_library()規(guī)則完成生成與鏈接倉庫中對應(yīng)規(guī)則見 upb_generator/ 及 upb/bazel/ 目錄下的構(gòu)建邏輯。來自 MiniDescriptor用戶可以在運行時把 MiniDescriptor 構(gòu)建為 MiniTable。MiniDescriptor 是一種緊湊的、upb 專屬的線格式專門為此設(shè)計調(diào)用upb_MiniTable_Build()即可完成轉(zhuǎn)換。當前倉庫中該入口位于 upb/mini_descriptor/decode.h#L49-L52。來自 reflection如果已經(jīng)為某類型構(gòu)建了 reflection 數(shù)據(jù)結(jié)構(gòu)可通過upb_MessageDef_MiniTable()從upb_MessageDef取得對應(yīng)的upb_MiniTable。選擇準則設(shè)計文檔給出的實操指南已經(jīng)使用 reflection 的語言(3) 是顯而易見的首選回避 reflection 的語言在 (1) 與 (2) 之間若目標語言在給定平臺上參與標準二進制鏈接模型特別是通常用ld鏈接則用 (1)——即靜態(tài)加載static loading。靜態(tài)加載的優(yōu)點不需要任何運行時初始化啟動更快唯一例外是庫或二進制為位置無關(guān)代碼時ELF/Mach-O loader 可能做的指針重定位有利于跨語言共享 proto message——共享通常要求雙方使用完全相同的 MiniTable。靜態(tài)加載的主要缺點需要為每個.proto生成一個.upb.c文件并鏈接其傳遞閉包內(nèi)所有.upb.c。Bazel 下這相對容易其他構(gòu)建系統(tǒng)會麻煩一些。而 (2) 的動態(tài)加載優(yōu)點是不需要為每條消息鏈接 C 代碼。對許多語言工具鏈來說為每個 protobuf 文件或消息類型生成并鏈接自定義 C 代碼是沉重負擔MiniDescriptor 提供了一種無需跨越核心運行時之外的 FFI 邊界即可加載 MiniTable 的便捷途徑。動態(tài)加載的常見模式是把包含 MiniDescriptor 的字符串直接嵌入生成代碼。例如 Dart 生成代碼中對純原始字段 message 的樣子const desc r$(),*-#$%! /10; _accessor $pb.instance.registry.newMessageAccessor(desc);newMessageAccessor()的實現(xiàn)基本就是upb_MiniTable_Build()的包裝從 MiniDescriptor 構(gòu)建 MiniTable。在代碼生成器中MiniDescriptor 可由upb_MessageDef_MiniDescriptorEncode()API 獲得——用戶永遠不需要手工編碼 MiniDescriptor。MiniTable 的鏈接Linking動態(tài)構(gòu)建 MiniTable 時把每條 message 鏈接到其子 message 和 enum 是用戶的責任每條 message 的 message 類型字段和 closed enum 字段必須分別用upb_MiniTable_SetSubMessage()和upb_MiniTable_SetSubEnum()鏈接還有一個高層函數(shù)upb_MiniTable_Link()一次鏈接所有字段它與upb_MiniTable_GetSubList()是絕配——后者可以在代碼生成器中列出所有需要傳給upb_MiniTable_Link()的 message 和 enum。這些接口在倉庫中的位置與語義可參見 upb/mini_descriptor/link.hupb_MiniTable_GetSubList()獲取子依賴清單見 upb/mini_descriptor/link.h#L61upb_MiniTable_Link()執(zhí)行批量鏈接見 upb/mini_descriptor/link.h#L71。常見模式是把link()調(diào)用直接嵌入生成代碼例如 Dart 中構(gòu)建含子 message 與 enum 的 MiniTableconst desc r$3334; _accessor $pb.instance.registry.newMessageAccessor(desc); _accessor!.link( [ M2.$_accessor, M3.$_accessor, M4.$_accessor, ], [ E.$_accessor, ], );這里upb_MiniTable_GetSubList()在代碼生成器中發(fā)現(xiàn)了 3 個子 message 字段和 1 個子 enum 字段需要鏈接運行時這份 MiniTable 列表被傳入link()其內(nèi)部調(diào)用upb_MiniTable_Link()。兩點補充某些應(yīng)用可能作為樹搖tree shaking策略的一部分選擇推遲甚至跳過注冊某些子 message 類型使用靜態(tài) MiniTable 時不需要手工鏈接步驟因為鏈接由ld自動完成。MiniTable 與 closed enumMiniTable 主要承載 message、field 與 extension 的數(shù)據(jù)但對于 closed enum還需要一個upb_MiniTableEnum結(jié)構(gòu)保存該 enum 中定義的所有數(shù)值集合——原因是 closed enum 有一個麻煩的行為未知 enum 值會被放入 unknown field set。設(shè)計文檔判斷隨著 editions 的推進 closed enum 將逐步淡出upb_MiniTableEnum的相關(guān)性與開銷會隨之縮小直至消失。Reflectionupb full 的完整 schemaReflection 使用upb_MessageDef、upb_FieldDef等類型在運行時表示.proto文件的完整內(nèi)容。它們是 upb 中g(shù)oogle::protobuf::Descriptor、google::protobuf::FieldDescriptor等的直接對應(yīng)物。一個值得注意的命名約定upb 一律用Def替代 C 的DescriptorDef不到Descriptor長度的 1/3目的是節(jié)省 C 代碼中每行都要重復(fù)類型名的橫向空間例如upb_FieldDef_Name()對比upb_FieldDescriptor_Name()。這有意與 C 命名分叉是刻意的設(shè)計決策。需要 reflection 的操作示例// Parses JSON format into a message object, using reflection. UPB_API bool upb_JsonDecode(const char* buf, size_t size, upb_Message* msg, const upb_MessageDef* m, const upb_DefPool* symtab, int options, upb_Arena* arena, upb_Status* status);upb_DefPool是構(gòu)建并擁有一組 def 的頂層容器是 Cgoogle::protobuf::DescriptorPool的緊密對應(yīng)物用戶必須始終保證upb_DefPool的壽命長于它所擁有的任何 def 對象。倉庫中upb_DefPool的核心實現(xiàn)見 upb/reflection/def_pool.h 與upb/reflection/def_pool.c。Reflection 的兩種加載方式來自 C 生成代碼upb 代碼生成器可以創(chuàng)建foo.upbdefs.c文件嵌入 descriptor 并導(dǎo)出 C 函數(shù)把它們加入用戶提供的upb_DefPool來自 descriptor用戶可對運行時獲得的 descriptor 手工調(diào)用upb_DefPool_AddFile()見 upb/reflection/def_pool.h#L86隨后用upb_DefPool_FindMessageByName()見 upb/reflection/def_pool.h#L39-L40按名取出單個 message 的 def。與 MiniTable 不同從生成代碼加載 reflection 需要運行時初始化upb_MessageDef這類 reflection 數(shù)據(jù)結(jié)構(gòu)無法像upb_MiniTable那樣直接發(fā)射進.rodata。生成代碼是把序列化后的 descriptor proto 嵌入.rodata運行時再構(gòu)建為堆對象。由此不能簡單認為 (1) 只是 (2) 的便利包裝(1)確實鏈接了靜態(tài).upb.c中的 MiniTable 結(jié)構(gòu)而 (2) 會在堆上從頭構(gòu)建 MiniTable因此 (1) 在把 descriptor 加載進upb_DefPool時 CPU 和 RAM 略省更關(guān)鍵的是(1) 得到的 descriptor 能夠反射基于生成的.upb.cMiniTable 構(gòu)建的 message而 (2) 得到的 descriptor 擁有各不相同的 MiniTable無法反射使用生成 MiniTable 的 message。PHP、Ruby、Python 這類動態(tài)語言的常見模式是用 (2) 配合嵌入生成代碼的 descriptor。Python 生成代碼當前的樣子from google.protobuf import descriptor_pool as _descriptor_pool from google.protobuf.internal import builder as _builder _desc b\n\x1aprotoc_explorer/main.proto\x12\x03pkg DESCRIPTOR _descriptor_pool.Default().AddSerializedFile(_desc) _globals globals() _builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, _globals) _builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, google3.protoc_explorer.main_pb2, _globals)上面的AddSerializedFile()本質(zhì)上就是upb_DefPool_AddFile()的薄包裝。倉庫中 Python 實現(xiàn)python/ 目錄含descriptor_pool.c等 C 層代碼與 C 內(nèi)核的這條銜接路徑正是設(shè)計文檔所描述模式的落地。upb 在倉庫中的落地從內(nèi)核到語言綁定從源碼結(jié)構(gòu)看設(shè)計文檔中各概念在倉庫內(nèi)都有對應(yīng)落點可作為繼續(xù)深入的入口設(shè)計概念倉庫位置說明Arena 內(nèi)存模型upb/mem/arena.h、upb/mem/arena.cupb_Arena_Init/Free/Fuse/Malloc以及RefArena/IncRefFor等包裝層原語MiniTable 數(shù)據(jù)結(jié)構(gòu)upb/mini_table/message.h、field.h、enum.h、extension_registry.c等message/field/enum/擴展注冊表MiniDescriptor 構(gòu)建upb/mini_descriptor/decode.h、upb/mini_descriptor/link.hupb_MiniTable_Build、upb_MiniTable_Link等Reflectionupb/reflection/def_pool.h、def.h、field_def.c等upb_DefPool_AddFile、upb_MessageDef等代碼生成器bootstrap 編譯鏈upb_generator/minitable/、reflection/、stage0/、upb_generator/bootstrap_compiler.bzl生成.upb.c/.upbdefs.c用stage0引導(dǎo)自舉一致性驗證conformance/ 與 upb/conformance/各語言后端的 failure list 區(qū)分 cc/upb 實現(xiàn)語言綁定示例lua/upb.c、lua/upb.lua、rust/、python/“把 upb 封裝進語言運行時”的真實樣例其中 Lua 綁定lua/目錄中的upb.c/upb.lua/test_upb.lua是體量最小的完整封裝樣本適合想理解“如何把 C 內(nèi)核包進一門語言”的讀者作為起點閱讀。小結(jié)upb 的設(shè)計可以濃縮為三個關(guān)鍵決策三者共同服務(wù)于“可被任意語言運行時低成本封裝”這一總目標不追求 API 穩(wěn)定與安全換取小體積、高性能與自由演進的空間——upb 的定位是內(nèi)核而非 SDK一切分配經(jīng)由upb_Arena用 bump allocator 整體釋放換取分配/釋放速度用upb_Arena_Fuse和引用原語解決跨 arena 懸垂指針問題用upb_Arena_Init的初始塊 自定義分配器支持無堆環(huán)境雙層 SchemaMiniTableupb lite與 Reflectionupb full前者以字段號與類型的緊湊表示支撐二進制線格式并可靜態(tài)鏈接進.rodata后者承載完整.proto語義支撐 JSON/TextFormat 與 options 訪問且 Reflection 內(nèi)嵌 MiniTable、單向可降級、不可升級。對正在評估“為一種新語言實現(xiàn) protobuf 支持”的工程師而言upb 的設(shè)計文檔與上述源碼路徑給出了一條被 Python、Rust、PHP、Ruby、Lua、Dart 等綁定反復(fù)驗證過的路線在語言運行時與 C 內(nèi)核之間用 Arena 解決內(nèi)存歸屬用 MiniTable 或 MiniDescriptor 解決 schema 獲取把 FFI 面收斂到極小?！久赓M下載鏈接】protobufProtocol Buffers - Googles data interchange format項目地址: https://gitcode.com/GitHub_Trending/pr/protobuf創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考