<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Memory-Pool on Jasper</title><link>https://jasper-aa64.github.io/tags/memory-pool/</link><description>Recent content in Memory-Pool on Jasper</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jasper-aa64.github.io/tags/memory-pool/index.xml" rel="self" type="application/rss+xml"/><item><title>Trading System Notes #3: Memory Pools and Allocators</title><link>https://jasper-aa64.github.io/posts/hot-path-memory-allocators/</link><pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/hot-path-memory-allocators/</guid><description>Every technique in this post does the same thing at a different layer: move an uncertain, kernel-involving operation off the hot path and force it to happen once, upfront, before it can ambush a single request. An object pool replaces malloc&amp;rsquo;s variable-cost search with an always-O(1) free list. mlockall and careful mallopt tuning stop the kernel from quietly taking pages back — and pre-faulting closes the one gap mlock alone leaves open. A hand-rolled arena allocator makes the STL itself cooperate with a custom allocator backed by bump-pointer memory. std::pmr solves the same STL-cooperation problem the standard library&amp;rsquo;s way — trading compile-time speed for runtime flexibility.</description></item></channel></rss>