# Global, thread-safe allocator that eventually returns pages to the OS

**URL:** <https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628>\
**Category:** Help\
**Tags:** memory-management\
**Created:** [July 10, 2026, 10:46am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628 "2026-07-10T10:46:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![DanielvNiek](https://ziggit.dev/user_avatar/ziggit.dev/danielvniek/32/8259_2.png) [@DanielvNiek](https://ziggit.dev/u/DanielvNiek)\
**Post date:** [July 10, 2026, 10:46am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628/1 "2026-07-10T10:46:37Z")

</div>

I only discovered today that both the debug allocator (gpa) and the smp allocator indefinitely caches small/medium allocations. Firstly is this correct?

If the above is correct, what would a good way be to have some global backing allocator(s) for my http request based arena allocators. However the backing allocator(s) should periodically (merge and?) return pages to the os, preventing bursts of allocations indefinitely keeping that memory cached.

The first solution i could think of was having two global debug/smp allocators that the program atomically toggles between every hour, at which point the one being toggled to, is first deinitialized, starting it from a clean slate. Obviously I would not use these for memory allocations that need to live longer than an hour (e.g. postgres pool of clients).

Thanks for any help in advance.

---

<div class="post-metadata">

**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\
**Post date:** [July 10, 2026, 10:55am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628/2 "2026-07-10T10:55:08Z")

</div>

Debug allocator returns pages as soon as possible and avoids reusing them, this makes it much more likely a use after free crashes your program.

smp certainly reuses memory using whatever algorithm it does, I can’t remember.

There is `std.heap.page_allocator`, but this always uses pages even if you request smaller amounts of memory, so it is best used to back other allocators (it is often the default).

I am confused on what behaviour you are asking for exactly?

perhaps this helps [Documentation - The Zig Programming Language](https://ziglang.org/documentation/master/#Choosing-an-Allocator)

---

<div class="post-metadata">

**Author:** ![DanielvNiek](https://ziggit.dev/user_avatar/ziggit.dev/danielvniek/32/8259_2.png) [@DanielvNiek](https://ziggit.dev/u/DanielvNiek)\
**Post date:** [July 10, 2026, 10:58am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628/3 "2026-07-10T10:58:13Z")

</div>

Sorry I guess my request is very confusing. To really simplify it, I want the most performant thread safe allocator that smartly caches pages from the OS, but not indefinitely, resulting in optimal cpu/memory balance.

---

<div class="post-metadata">

**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\
**Post date:** [July 10, 2026, 11:00am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628/4 "2026-07-10T11:00:33Z")

</div>

the closest fit would be `smp_allocator`, or if your linking libc use the `c_allocator`

But what is most optimal is specific to your usecase, and AFAIK neither of those allocators allow you to configure that.

regardless, for development `DebugAllocator` is good to help catch bugs, though it might be too slow for your program.

---

<div class="post-metadata">

**Author:** ![DanielvNiek](https://ziggit.dev/user_avatar/ziggit.dev/danielvniek/32/8259_2.png) [@DanielvNiek](https://ziggit.dev/u/DanielvNiek)\
**Post date:** [July 10, 2026, 11:08am UTC](https://ziggit.dev/t/global-thread-safe-allocator-that-eventually-returns-pages-to-the-os/16628/5 "2026-07-10T11:08:12Z")

</div>

Thanks for confirming this, helps a lot with my mental model of these allocators. The usecase is a web server so still using ArenaAllocator on each request, but would want its backing allocator to also cache pages from the os. Think I will just stick with the smp allocator in production until I see the memory usage causing problems.