#memory-management
Posts
-
Digging into MariaDB's Source 2: The Big Picture — the Server Layer, Storage Engines, and the Life of One Query
The map for this series, written for intermediate developers opening the MariaDB source for the first time. Why the server layer (sql/) and the storage engines (storage/) are separate, what their boundary looks like — handler (one opened table) and handlerton (one table of function pointers per engine) — the path one SELECT takes from connection → THD → parsing → preparation → optimization → execution → handler → engine and back through Protocol, and MEM_ROOT, which throws all those objects away in one go after every statement. Checked against the real source and gdb backtraces.
-
Digging into nginx's Source 3: Memory Pools and Core Data Structures — ngx_pool_t, ngx_str_t, ngx_buf_t and ngx_chain_t
You will hardly find free() in nginx's C code either. Memory that shares a lifetime — one request, one connection — goes into a pool and is thrown away in one go. This post checks, against the real source, debug logs and gdb, how ngx_pool_t chains its blocks and uses the failed counter, the separate large list for big allocations, cleanups, the non-NUL-terminated ngx_str_t, arrays, lists, queues and hashes, and the ngx_buf_t and ngx_chain_t that carry responses.
-
Digging into Apache httpd's Source 4: APR Memory Pools — Managing Memory Without free()
You will hardly find free() in httpd's C code. Instead of handing memory back piece by piece, httpd groups everything with the same lifetime — "one request", "one connection" — into a pool and throws it away in one go. This post looks at APR pool nodes and the allocator, why apr_palloc is just a pointer bump, the order cleanups run in, where httpd creates and destroys its pools, and the two classic mistakes — all checked against the real source and real runs.