Project: YDB (App Definition and Development / Database)
File: DESIGN.md

upb aims to be a minimal C protobuf kernel. It has a C API, but its primary goal is to be the core runtime for a higher-level API. Full protobuf conformance Small code size Fast performance (without compromising code size) Easy to wrap in language runtimes Easy to adapt to different memory management schemes (refcounting, GC, etc) C99 32 or 64-bit CPU (assumes 4 or 8 byte pointers) Uses pointer tagging, but avoids other implementation-defined behavior Aims to never invoke undefined behavior (tests with ASAN, UBSAN, etc) No global state, fully re-entrant The upb library is divided into two main parts: A core message representation, which supports binary format parsing and serialization. `upb/upb.h`: arena allocator (`upb_arena`) `upb/msg_internal.h`: core message representation and parse tables `upb/msg.h`: accessing metadata common to all messages, like unknown fields `upb/decode.h`: binary format parsing `upb/encode.h`: binary format serialization `upb/table_internal.h`: hash table (used for maps) `upbc/protoc-gen-upbc.cc`: compiler that generates `.upb.h`/`.upb.c` APIs for accessing messages without reflection. A reflection add-on library that supports JSON and text format. `upb/def.h`: schema representation and loading from descriptors `upb/reflection.h`: reflective access to message data. `upb/json_encode.h`: JSON encoding `upb/json_decode.h`: JSON decoding `upb/text_encode.h`: text format encoding `upbc/protoc-gen-upbdefs.cc`: compiler that generates `.upbdefs.h`/`.upbdefs.c` APIs for loading reflection. The representation for each message consists of: One pointer (`upbmsginternaldata*`) for unknown fields and extensions. This pointer is `NULL` when no unknown fields or extensions are present. Hasbits for any optional/required fields. Case integers for each oneof. Data for each field. For example, a layout for a message with two `optional int32` fields would end up looking something like this: ```c // For illustration only, upb does not actually generate structs. typedef struct { upbmsginternaldata* internal; // Unknown fields and extensions. uint32_t hasbits; // We are only using two hasbits. int32_t field1; int32_t field2; } packagenameMessageName; ``` Note in particular that messages do not have: A pointer to reflection or a parse table (upb messages are not self-describing). A pointer to an arena (the arena must be explicitly passed into any function that allocates). The upb compiler computes a layout for each message, and determines the offset for each field using normal alignment rules (each data member must be aligned to a multiple of its size). This layout is then embedded into the generated `.upb.h` and `.upb.c` headers in two different forms. First as inline accessors that expect the data at a given offset: ```c // Example of a generated accessor, from foo.upb.h UPBINLINE int32t packagenameMessageName_field1( const upbtestMessageName *msg) { return *UPBPTRAT(msg, UPBSIZE(4, 4), int32t); } ``` Secondly, the layout is emitted as a table which is used by the parser and serializer. We call these tables "mini-tables" to distinguish them from the larger and more optimized "fast tables" used in `upb/decode_fast.c` (an experimental parser that is 2-3x the speed of the main parser, though the main parser is already quite fast). ```c // Definition of mini-table structure, from upb/msg_internal.h typedef struct { uint32_t number; uint16_t offset; int16t presence; /* If >0, hasbitindex. If <0, ~oneof_index. */ uint16t submsgindex; / undefined if descriptortype != MESSAGE or GROUP. / uint8_t descriptortype; int8t mode; /* upbfieldmode, with flags from upb_labelflags */ } upbmsglayoutfield; typedef enum { UPBMODE_MAP = 0, UPBMODE_ARRAY = 1, UPBMODE_SCALAR = 2, } upb_fieldmode; typedef struct { const struct upb_msglayout const submsgs; const upbmsglayoutfield *fields; uint16_t size; uint16t fieldcount; bool extendable; uint8t densebelow; uint8t tablemask; } upb_msglayout; // Example of a generated mini-table, from

static const upbmsglayoutfield upbtestMessageNamefields[2] = { {1, UPBSIZE(4, 4), 1, 0, 5, UPBMODESCALAR}, {2, UPBSIZE(8, 8), 2, 0, 5, UPBMODESCALAR}, }; const upbmsglayout upbtestMessageNamemsginit = { NULL, &upbtestMessageNamefields[0], UPB_SIZE(16, 16), 2, false, 2, 255, }; ``` The upb compiler computes separate layouts for 32 and 64 bit modes, since the pointer size will be 4 or 8 bytes respectively. The upb compiler embeds both sizes into the source code, using a `UPB_SIZE(size32, size64)` macro that can choose the appropriate size at build time based on the size of `UINTPTR_MAX`. Note that `.upb.c` files contain data tables only. There is no "generated code" except for the inline accessors in the `.upb.h` files: the entire footprint of `.upb.c` files is in `.rodata`, none in `.text` or `.data`. All memory management in upb is built around arenas. A message is never considered to "own" the strings or sub-messages contained within it. Instead a message and all of its sub-messages/strings/etc. are all owned by an arena and are freed when the arena is freed. An entire message tree will probably be owned by a single arena, but this is not required or enforced. As far as upb is concerned, it is up to the client how to partition its arenas. upb only requires that when you ask it to serialize a message, that all reachable messages are still alive. The arena supports both a user-supplied initial block and a custom allocation callback, so there is a lot of flexibility in memory allocation strategy. The allocation callback can even be `NULL` for heap-free operation. The main constraint of the arena is that all of the memory in each arena must be freed together. `upb_arena` supports a novel operation called "fuse". When two arenas are fused together, their lifetimes are irreversibly joined, such that none of the arena blocks in either arena will be freed until both arenas are freed with `upbarenafree()`. This is useful when joining two messages from separate arenas (making one a sub-message of the other). Fuse is a very cheap operation, and an unlimited number of arenas can be fused together efficiently. upb offers a fully-featured reflection library. There are two main ways of using reflection: You can load descriptors from strings using `upbsymtabaddfile()`. The upb runtime will dynamically create mini-tables like what the upb compiler would have created if you had compiled this type into a `.upb.c` file. You can load descriptors using generated `.upbdefs.h` interfaces. This will load reflection that references the corresponding `.upb.c` mini-tables instead of building a new mini-table on the fly. This lets you reflect on generated types that are linked into your program. upb's design for descriptors is similar to protobuf C++ in many ways, with the following correspondences: | C++ Type | upb type | | | | | `google::protobuf::DescriptorPool` | `upb_symtab` | `google::protobuf::Descriptor` | `upb_msgdef` | `google::protobuf::FieldDescriptor` | `upb_fielddef` | `google::protobuf::OneofDescriptor` | `upb_oneofdef` | `google::protobuf::EnumDescriptor` | `upb_enumdef` | `google::protobuf::FileDescriptor` | `upb_filedef` | `google::protobuf::ServiceDescriptor` | `upb_servicedef` | `google::protobuf::MethodDescriptor` | `upb_methoddef` Like in C++ descriptors (defs) are created by loading a `googleprotobufFileDescriptorProto` into a `upb_symtab`. This creates and links all of the def objects corresponding to that `.proto` file, and inserts the names into a symbol table so they can be looked up by name. Once you have loaded some descriptors into a `upb_symtab`, you can create and manipulate messages using the interfaces defined in `upb/reflection.h`. If your descriptors are linked to your generated layouts using option (2) above, you can safely access the same messages using both reflection and generated interfaces.