--- title: Static Allocation, Constant Work | daily.dev description: Discusses how object pools and static allocation reduce the severity of use-after-free bugs, moving from arbitrary code execution to safer, more constrained... canonical: https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Static Allocation, Constant Work | daily.dev og:description: Discusses how object pools and static allocation reduce the severity of use-after-free bugs, moving from arbitrary code execution to safer, more constrained... og:url: https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7 og:image: https://api.daily.dev/og/posts/VGCrnLVS7.png og:image:alt: Static Allocation, Constant Work og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Static Allocation, Constant Work **[matklad](https://daily.dev/sources/matklad)** · 6 min read · 0 upvotes · 0 comments ## Summary Discusses how object pools and static allocation reduce the severity of use-after-free bugs, moving from arbitrary code execution to safer, more constrained memory aliasing. Explains TigerBeetle's TigerStyle patterns: allocating a fixed maximum number of objects at startup rather than dynamic allocation, and designing systems to always process a constant amount of work (using neutral/reserved placeholder states) instead of tracking live vs dead objects. Argues these patterns give predictable failure modes, flat P100 latency under load, and simpler, more exhaustively verifiable state transitions, at the cost of some memory and CPU efficiency in the common case. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does using an object pool change the severity of a use-after-free bug compared to plain malloc/free? With plain malloc and free, a use-after-free can cause type confusion, since a freed memory location can be reused by an object of a completely different type, letting a user-controlled integer overlap with a function pointer and enable arbitrary code execution. With an object pool holding dead objects of a single type, aliasing still occurs but without type confusion, since the reused memory is still the same type, producing deterministic (if logically wrong) behavior unless the type contains an inline enum. _Developers hardening allocators against use-after-free exploits can find deeper systems security writeups through daily.dev._ ### Why does TigerBeetle preallocate a fixed maximum number of orders at startup instead of allocating dynamically? Preallocating a fixed maximum, such as orders_max, ensures the system either fails to start due to insufficient memory or, once running, can handle full load without risking an out-of-memory kill from the kernel that could terminate the entire matching engine or its supervisor process. This static allocation approach trades flexibility for a guarantee of graceful degradation under overload rather than catastrophic failure. _Engineers designing overload-resilient services can track patterns like static allocation limits via daily.dev._ ### What is the constant work pattern and why does TigerBeetle iterate over all orders including inactive ones? The constant work pattern always processes the full fixed-size set of items, treating unused slots as no-op reserved orders instead of maintaining a separate collection of only live orders. This makes iteration easier to vectorize and cache-prefetch than index-based tracking, and guarantees that worst-case (maximum load) performance is discovered during testing rather than in production, keeping P100 latency flat regardless of load. _Teams optimizing for predictable worst-case latency can follow performance-pattern discussions on daily.dev._ ## Similar posts on daily.dev - [Static Allocation For Compilers](https://daily.dev/posts/static-allocation-for-compilers-jjuf4dofn) · matklad · 1 upvotes · 0 comments --- Tags: [#zig](https://daily.dev/tags/zig) [View this post on daily.dev](https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Static Allocation, Constant Work","url":"https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7"},"datePublished":"2026-09-02T17:31:47.350Z","dateModified":"2026-09-02T18:30:43.816Z","description":"Discusses how object pools and static allocation reduce the severity of use-after-free bugs, moving from arbitrary code execution to safer, more constrained...","image":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","thumbnailUrl":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","isAccessibleForFree":true,"articleSection":"matklad","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"matklad","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/c34dbbf360354a179786e8a127718b12","url":"https://daily.dev/sources/matklad"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"zig","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"matklad","item":"https://daily.dev/sources/matklad"},{"@type":"ListItem","position":3,"name":"Static Allocation, Constant Work"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/static-allocation-constant-work-vgcrnlvs7#faq","mainEntity":[{"@type":"Question","name":"How does using an object pool change the severity of a use-after-free bug compared to plain malloc/free?","acceptedAnswer":{"@type":"Answer","text":"With plain malloc and free, a use-after-free can cause type confusion, since a freed memory location can be reused by an object of a completely different type, letting a user-controlled integer overlap with a function pointer and enable arbitrary code execution. With an object pool holding dead objects of a single type, aliasing still occurs but without type confusion, since the reused memory is still the same type, producing deterministic (if logically wrong) behavior unless the type contains an inline enum. Developers hardening allocators against use-after-free exploits can find deeper systems security writeups through daily.dev."}},{"@type":"Question","name":"Why does TigerBeetle preallocate a fixed maximum number of orders at startup instead of allocating dynamically?","acceptedAnswer":{"@type":"Answer","text":"Preallocating a fixed maximum, such as orders_max, ensures the system either fails to start due to insufficient memory or, once running, can handle full load without risking an out-of-memory kill from the kernel that could terminate the entire matching engine or its supervisor process. This static allocation approach trades flexibility for a guarantee of graceful degradation under overload rather than catastrophic failure. Engineers designing overload-resilient services can track patterns like static allocation limits via daily.dev."}},{"@type":"Question","name":"What is the constant work pattern and why does TigerBeetle iterate over all orders including inactive ones?","acceptedAnswer":{"@type":"Answer","text":"The constant work pattern always processes the full fixed-size set of items, treating unused slots as no-op reserved orders instead of maintaining a separate collection of only live orders. This makes iteration easier to vectorize and cache-prefetch than index-based tracking, and guarantees that worst-case (maximum load) performance is discovered during testing rather than in production, keeping P100 latency flat regardless of load. Teams optimizing for predictable worst-case latency can follow performance-pattern discussions on daily.dev."}}]} ```