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