16.5 Memory Allocators

In the C memory chapter you learned that every value lives somewhere: on the stack (fast, automatic, gone the instant a function returns) or on the heap (lives as long as you want, but you had to ask the operating system for it with something like malloc, and you have to give it back yourself). You also learned that a pointer is just a number — the address of a byte in memory. This chapter takes those two ideas and puts them to work on a very practical problem: calling malloc and new directly, thousands of times a second, for the entire length of a play session, is exactly the kind of thing a shipped game cannot get away with. You're going to build the tools real engines use instead: allocators (small pieces of code that manage a block of memory for you) that ask the OS for memory once, then hand it out themselves, fast and predictably.

1. Why Not Just malloc/new Everywhere?

malloc and new are general-purpose tools. They have to work for any size, called from any thread, freed in any order, for the entire life of the program. That generality is expensive, and it costs you in three separate ways:

• Speed. A general allocator has bookkeeping to do on every call — searching internal lists for a free chunk of the right size, and often taking a lock so that two threads calling malloc at the same time don't corrupt its internal data.
• Predictability. Most calls are fast, but every so often the allocator has to go ask the OS for more memory (a real system call), which can take vastly longer than a normal call. A game has about 16.6 milliseconds to produce a frame at 60 FPS — a single unlucky allocation that takes 2 milliseconds is a visible stutter.
• Fragmentation. Over hours of gameplay, with thousands of allocations and frees of different sizes happening in an unpredictable order, the free memory left behind gets chopped into small, scattered pieces (covered in detail below).

Let's see the speed cost directly. Here's a small, runnable program that just allocates and frees, over and over, and times how long that takes:

#include <chrono>
#include <cstdio>

int main() {
    const int COUNT = 2000000;

    auto start = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < COUNT; i++) {
        int* p = new int[16];   // 64 bytes each
        p[0] = i;                // touch it, so the compiler can't optimize the alloc away
        delete[] p;
    }
    auto end = std::chrono::high_resolution_clock::now();

    double ms = std::chrono::duration<double, std::milli>(end - start).count();
    printf("2,000,000 new/delete pairs: %.2f ms\n", ms);
    return 0;
}

A typical run on an ordinary laptop prints something like:

2,000,000 new/delete pairs: 58.31 ms

Your exact number depends on your CPU, your OS's allocator, and whatever else is running — that's the point, it's unpredictable. But the shape holds everywhere: a few tens of nanoseconds per call adds up fast, and under real load — multiple threads fighting over the same global heap lock, and fragmentation making the search for a free chunk slower — that number gets worse, and worse in a way you can't easily predict ahead of time. That unpredictability is the real enemy for code that has to hit a fixed frame budget every single frame.

Fragmentation: Free Bytes That Aren't Free

Here's the part that gets worse the longer your game runs, not the more allocations you do per frame. Imagine a heap after a busy few minutes of gameplay: objects of many different sizes have been allocated and freed, in an order nothing like the order they were requested in.

"Free" does not mean "usable." An allocator can only hand out a single, unbroken (contiguous) run of bytes — it can't stitch together three separate 20-byte gaps to satisfy a 60-byte request. Every time your game allocates and frees objects of different sizes in a different order than they came in, it leaves gaps like this. Over a two-hour play session, with thousands of temporary objects of every size passing through the same heap, those gaps accumulate until even a small allocation can fail — not because you're out of memory, but because you're out of contiguous memory.

2. The Big Idea: One Big Block, Managed by You

The fix used by essentially every game engine is simple to state: stop calling malloc/new during gameplay at all. Instead, at startup, ask the OS for one big block of memory in a single call — way more than you need for any one thing, but a fixed, known amount. From then on, every system in the game (physics, audio, rendering, AI) asks your own code for memory, and your own code just does simple pointer arithmetic to hand out pieces of that one block. No more OS calls, no more locks, no more surprises, for the rest of the program's life.

#include <cstdlib>
#include <cstdio>

class MemoryArena {
public:
    void Init(size_t sizeBytes) {
        base = static_cast<unsigned char*>(std::malloc(sizeBytes));
        capacity = sizeBytes;
        used = 0;
    }

    void Shutdown() {
        std::free(base);
        base = nullptr;
    }

    unsigned char* base = nullptr;
    size_t capacity = 0;
    size_t used = 0;
};

int main() {
    MemoryArena arena;
    arena.Init(64 * 1024 * 1024); // 64 MB, ONE malloc call for the whole game

    printf("Reserved %zu bytes from the OS in a single call.\n", arena.capacity);
    printf("From here on, every game system asks THIS object for memory,\n");
    printf("never malloc/new directly.\n");

    arena.Shutdown();
    return 0;
}

Reserved 67108864 bytes from the OS in a single call.
From here on, every game system asks THIS object for memory,
never malloc/new directly.

Everything in the rest of this chapter is a different strategy for slicing up that one block: a way of deciding which bytes to hand out next, and how to know when they can be reused. Different game data has a different lifetime (per-frame, per-level, per-object, forever), and each strategy below is shaped around one of those lifetimes.

3. Alignment: Why Bytes Need to Line Up

Before building any allocator, there's one piece of pointer arithmetic every one of them needs: alignment. Alignment means an address is a multiple of some number, usually a power of two (4, 8, 16...). CPUs don't read memory one byte at a time; they read in fixed-size chunks (words), and hardware instructions (especially SIMD instructions, which operate on 16 bytes at once) often flatly require their data to start on an aligned address.

#include <cstdint>
#include <cstdio>

uintptr_t AlignUp(uintptr_t address, size_t align) {
    // align MUST be a power of two (4, 8, 16, ...)
    return (address + align - 1) & ~(align - 1);
}

int main() {
    printf("alignof(int)    = %zu\n", alignof(int));
    printf("alignof(double) = %zu\n", alignof(double));

    uintptr_t addr = 1001; // pretend this is a raw byte address
    printf("1001 aligned to 4  -> %llu\n", (unsigned long long)AlignUp(addr, 4));
    printf("1001 aligned to 16 -> %llu\n", (unsigned long long)AlignUp(addr, 16));
    return 0;
}

alignof(int)    = 4
alignof(double) = 8
1001 aligned to 4  -> 1004
1001 aligned to 16 -> 1008

AlignUp is a trick worth understanding, not just memorizing: align - 1 is a run of 1-bits (for align = 16, that's 0b1111). Adding it to address pushes the value past the next boundary, and ANDing with ~(align - 1) (all those low bits flipped and inverted) clears the low bits back down, snapping the result down to the nearest multiple of align at or above the original address. Every allocator in this chapter uses exactly this formula.

4. The Linear (Arena) Allocator: Bump a Pointer

The simplest possible allocator keeps one number: an offset into the block, starting at 0. Alloc(size) aligns the offset, checks there's enough room, hands back a pointer at the current offset, then moves the offset forward by size. That's it — no searching, no bookkeeping per allocation. This is called a linear allocator or arena, and the operation is often called "bumping the pointer."

#include <cstdint>
#include <cstddef>

class LinearAllocator {
public:
    void Init(void* memory, size_t sizeBytes) {
        base = static_cast<unsigned char*>(memory);
        capacity = sizeBytes;
        offset = 0;
    }

    void* Alloc(size_t sizeBytes, size_t align = 8) {
        uintptr_t current = reinterpret_cast<uintptr_t>(base) + offset;
        uintptr_t aligned = (current + align - 1) & ~(align - 1);
        size_t padding = aligned - current;

        if (offset + padding + sizeBytes > capacity) {
            return nullptr; // out of space in this arena
        }

        offset += padding + sizeBytes;
        return reinterpret_cast<void*>(aligned);
    }

    void Reset() {
        offset = 0; // "free" EVERYTHING in one step -- no per-object work at all
    }

private:
    unsigned char* base = nullptr;
    size_t capacity = 0;
    size_t offset = 0;
};

malloc always hands back memory aligned to at least alignof(std::max_align_t), which is 16 bytes on a typical 64-bit machine — so if we back this arena with malloc, offset 0 already lines up with an 8-byte alignment. That lets us trace the exact offsets a sequence of calls returns:

#include <cstdlib>
#include <cstdio>

int main() {
    unsigned char* memory = static_cast<unsigned char*>(std::malloc(256));
    LinearAllocator arena;
    arena.Init(memory, 256);

    void* a = arena.Alloc(40);
    void* b = arena.Alloc(30);
    void* c = arena.Alloc(60);

    printf("a offset = %td\n", (unsigned char*)a - memory);
    printf("b offset = %td\n", (unsigned char*)b - memory);
    printf("c offset = %td\n", (unsigned char*)c - memory);

    arena.Reset();
    void* d = arena.Alloc(10);
    printf("d offset after Reset() = %td\n", (unsigned char*)d - memory);

    std::free(memory);
    return 0;
}

a offset = 0
b offset = 40
c offset = 72
d offset after Reset() = 0

Trace it by hand: a starts at offset 0 (already aligned), uses 40 bytes, so the offset becomes 40. b starts at 40 (40 is already a multiple of 8, no padding needed), uses 30 bytes, offset becomes 70. c starts at 70 — but 70 isn't a multiple of 8, so 2 padding bytes are inserted to reach 72, then 60 bytes are used, offset becomes 132. Calling Reset() snaps the offset straight back to 0, so d starts right back where a did.

This is the allocator to reach for whenever data only needs to survive one frame: scratch transforms for a render pass, a temporary buffer for a pathfinding search, string formatting for a debug overlay. Ask for a block once at startup, Alloc() from it all frame long, Reset() at the top of the next frame. Fragmentation is not just unlikely here — it's impossible, because nothing is ever freed individually. It's all-or-nothing, which is also exactly its limitation.

5. The Stack Allocator: LIFO with Markers

A stack allocator is a linear allocator with one extra trick: you can save the current offset as a marker, keep allocating, and later roll the offset back to that marker — freeing everything allocated after it, in one step, without touching anything allocated before it. The catch is the name: it only works LIFO (Last In, First Out, the same order rule a call stack itself follows). You must free markers in the reverse order you took them.

#include <cstdint>
#include <cstddef>

class StackAllocator {
public:
    using Marker = size_t;

    void Init(void* memory, size_t sizeBytes) {
        base = static_cast<unsigned char*>(memory);
        capacity = sizeBytes;
        offset = 0;
    }

    void* Alloc(size_t sizeBytes, size_t align = 8) {
        uintptr_t current = reinterpret_cast<uintptr_t>(base) + offset;
        uintptr_t aligned = (current + align - 1) & ~(align - 1);
        size_t padding = aligned - current;

        if (offset + padding + sizeBytes > capacity) {
            return nullptr;
        }

        offset += padding + sizeBytes;
        return reinterpret_cast<void*>(aligned);
    }

    Marker GetMarker() const {
        return offset;
    }

    void FreeToMarker(Marker marker) {
        offset = marker; // everything allocated AFTER this marker is gone
    }

private:
    unsigned char* base = nullptr;
    size_t capacity = 0;
    size_t offset = 0;
};

#include <cstdlib>
#include <cstdio>

int main() {
    unsigned char* memory = static_cast<unsigned char*>(std::malloc(256));
    StackAllocator stack;
    stack.Init(memory, 256);

    void* levelData = stack.Alloc(64);              // lives for the whole level
    StackAllocator::Marker frameMark = stack.GetMarker();

    void* pathBuffer = stack.Alloc(48);              // this frame's scratch work
    printf("offset with pathBuffer alive: %zu\n", stack.GetMarker());

    stack.FreeToMarker(frameMark);                   // done with this frame's scratch
    printf("offset after FreeToMarker:    %zu\n", stack.GetMarker());

    void* nextFrameBuffer = stack.Alloc(20);         // reuses the bytes pathBuffer used
    printf("nextFrameBuffer offset:       %td\n", (unsigned char*)nextFrameBuffer - memory);

    std::free(memory);
    return 0;
}

offset with pathBuffer alive: 112
offset after FreeToMarker:    64
nextFrameBuffer offset:       64

levelData takes the first 64 bytes, so the marker is saved at offset 64. pathBuffer takes 48 more bytes, pushing the offset to 112. Calling FreeToMarker(frameMark) snaps the offset straight back to 64 — levelData is untouched, but the 48 bytes pathBuffer used are now free again. Sure enough, the very next allocation, nextFrameBuffer, starts at offset 64: the exact same bytes pathBuffer was just using.

6. The Pool Allocator: Fixed-Size Blocks and a Free List

Neither of the two allocators above handles this common case well: lots of same-sized objects — bullets, particles, enemies — that get created and destroyed constantly, in an order that has nothing to do with when they were created. A pool allocator is built exactly for this. It slices the block into N fixed-size slots up front, and keeps a free list: a chain of the currently-unused slots, linked together. Alloc() pops the front of that list; Free() pushes a slot back onto the front. Both are O(1) — no searching, ever.

#include <cstddef>

class PoolAllocator {
public:
    void Init(void* memory, size_t blockSize, size_t blockCount) {
        // Each FREE block's first few bytes store a pointer to the NEXT
        // free block. That's the whole trick: the free list lives INSIDE
        // the free memory itself, at zero extra storage cost.
        unsigned char* p = static_cast<unsigned char*>(memory);
        this->blockSize = blockSize;
        freeList = reinterpret_cast<FreeBlock*>(p);

        for (size_t i = 0; i < blockCount - 1; i++) {
            FreeBlock* block = reinterpret_cast<FreeBlock*>(p + i * blockSize);
            block->next = reinterpret_cast<FreeBlock*>(p + (i + 1) * blockSize);
        }
        FreeBlock* last = reinterpret_cast<FreeBlock*>(p + (blockCount - 1) * blockSize);
        last->next = nullptr;
    }

    void* Alloc() {
        if (!freeList) {
            return nullptr; // pool is full
        }
        FreeBlock* block = freeList;
        freeList = freeList->next;   // pop the head
        return block;
    }

    void Free(void* ptr) {
        FreeBlock* block = static_cast<FreeBlock*>(ptr);
        block->next = freeList;      // push back onto the head
        freeList = block;
    }

private:
    struct FreeBlock {
        FreeBlock* next;
    };
    FreeBlock* freeList = nullptr;
    size_t blockSize = 0;
};

#include <cstdio>

struct Bullet {
    float x, y, z;
    float speed;
};

int main() {
    unsigned char memory[sizeof(Bullet) * 4];
    PoolAllocator bullets;
    bullets.Init(memory, sizeof(Bullet), 4);

    void* b0 = bullets.Alloc();
    void* b1 = bullets.Alloc();
    void* b2 = bullets.Alloc();
    printf("allocated 3 of 4 slots\n");

    bullets.Free(b1);              // b1 dies, e.g. it hit something
    printf("freed the middle slot (b1)\n");

    void* b3 = bullets.Alloc();    // reuses b1's slot immediately
    printf("b3 == b1? %s\n", (b3 == b1) ? "yes" : "no");

    void* b4 = bullets.Alloc();    // the last remaining free slot
    void* b5 = bullets.Alloc();    // pool is now full
    printf("b5 == nullptr? %s\n", (b5 == nullptr) ? "yes" : "no");

    return 0;
}

allocated 3 of 4 slots
freed the middle slot (b1)
b3 == b1? yes
b5 == nullptr? yes

The comment in Init() is worth re-reading: a free slot's own bytes are reused to store the "next" pointer of the free list. Nobody is treating that memory as a real Bullet while it's free, so it's safe to write a pointer there — and it means the free list costs zero extra memory beyond the slots themselves. This is exactly why pool allocators are the standard tool for bullets, particles, and enemies: create and destroy them in any order, as fast as a linked-list push/pop, with no fragmentation ever, because a freed slot is always exactly the right size for the next object of the same type.

7. The General-Purpose Free-List Allocator, Briefly

Sometimes you need the opposite of a pool: objects of many different sizes, freed in an unpredictable order, that aren't just scratch data for one frame — loading and unloading assets as the player moves between levels, for example. For this you need a general-purpose free-list allocator, which keeps a list of free blocks, each tagged with its own size:

struct FreeBlockHeader {
    size_t size;
    FreeBlockHeader* next;
};

Alloc(size) walks this list looking for a block big enough (the simplest rule, first-fit, just takes the first one that fits; best-fit takes the smallest one that still fits, trading search time for less wasted space). If the chosen block is much bigger than requested, it's split in two, with the leftover put back on the free list. Free(ptr) puts the block back on the list — and, critically, checks whether its immediate neighbors in memory are also free, merging them into one bigger block if so. This merging step is called coalescing, and it's the main defense a general-purpose allocator has against fragmentation.

If this sounds a lot like a description of how malloc itself works internally — it is. A general-purpose free-list allocator is genuinely general-purpose, which is exactly why section 1's speed and fragmentation problems apply to it too, just somewhat mitigated by coalescing. Engines do use this pattern, but they keep it out of the hot, every-frame path, reserving it for things that change relatively rarely: loading a level's worth of assets, not spawning a bullet.

8. Double-Buffered Frame Allocators

Modern engines are pipelined: while the GPU is still drawing frame N (reading vertex buffers, constants, and other per-frame data you handed it), the CPU has often already moved on to building frame N+1. If you reset a single arena at the start of every frame, you'd be overwriting memory the GPU hasn't finished reading yet — a race condition that shows up as flickering geometry or garbage on screen. The fix: keep two arenas, and swap which one is "live" every frame.

#include <cstdlib>

class FrameAllocator {
public:
    void Init(size_t sizeBytes) {
        bufferA.Init(std::malloc(sizeBytes), sizeBytes);
        bufferB.Init(std::malloc(sizeBytes), sizeBytes);
    }

    void BeginFrame() {
        usingA = !usingA;     // swap which buffer is "live"
        Current().Reset();    // safe: the OTHER buffer is what the GPU
                               // might still be reading from
    }

    void* Alloc(size_t sizeBytes, size_t align = 8) {
        return Current().Alloc(sizeBytes, align);
    }

    int CurrentIndex() const { return usingA ? 0 : 1; } // for debugging only

private:
    LinearAllocator& Current() { return usingA ? bufferA : bufferB; }

    LinearAllocator bufferA;
    LinearAllocator bufferB;
    bool usingA = false;
};

#include <cstdio>

int main() {
    FrameAllocator frameAlloc;
    frameAlloc.Init(1024);

    for (int frame = 0; frame < 4; frame++) {
        frameAlloc.BeginFrame();
        frameAlloc.Alloc(64); // e.g. this frame's transform matrices
        printf("frame %d writes into buffer %d\n", frame, frameAlloc.CurrentIndex());
    }
    return 0;
}

frame 0 writes into buffer 0
frame 1 writes into buffer 1
frame 2 writes into buffer 0
frame 3 writes into buffer 1

The pattern generalizes: some engines use three or more buffers ("triple buffering") if the CPU can get further ahead of the GPU than one frame. The core idea stays the same — never reset a buffer the reader (GPU, render thread, network thread, whatever) might not be finished with yet.

9. Tracking Allocations Per Subsystem

Once you have several custom allocators running — a physics arena, an audio pool, a rendering frame allocator, an AI scratch buffer — it gets hard to answer a simple question: when total memory use creeps up over a two-hour play session, who is using it? The fix is to tag every allocation with an owning subsystem, and keep a small running total per tag.

#include <cstdio>

enum class MemoryTag {
    Physics,
    Audio,
    Rendering,
    AI,
    Count // not a real tag -- just gives the array a size
};

struct MemoryTracker {
    size_t usedBytes[(int)MemoryTag::Count] = {};

    void Track(MemoryTag tag, size_t bytes) {
        usedBytes[(int)tag] += bytes;
    }

    void Untrack(MemoryTag tag, size_t bytes) {
        usedBytes[(int)tag] -= bytes;
    }

    void PrintReport() const {
        const char* names[] = { "Physics", "Audio", "Rendering", "AI" };
        for (int i = 0; i < (int)MemoryTag::Count; i++) {
            printf("%s: %zu bytes\n", names[i], usedBytes[i]);
        }
    }
};

int main() {
    MemoryTracker tracker;

    tracker.Track(MemoryTag::Physics, 4096);      // a rigid body pool
    tracker.Track(MemoryTag::Audio, 65536);        // a decoded music buffer
    tracker.Track(MemoryTag::Rendering, 1048576);  // this frame's arena
    tracker.Track(MemoryTag::AI, 2048);            // pathfinding scratch

    tracker.PrintReport();
    return 0;
}

Physics: 4096 bytes
Audio: 65536 bytes
Rendering: 1048576 bytes
AI: 2048 bytes

In a real engine, this isn't a separate manual step — each allocator instance (arena, pool, frame allocator) carries its own debug name and tag, reports its own high-water mark and current usage, and a memory profiler (an in-editor or in-game tool for browsing this data, which you'll see a concrete example of in section 11) reads that data live while the game runs. The version above is the same idea in miniature: know who owns every byte, not just how many bytes exist.

10. Debug Tricks: Guard Bytes and Poison Patterns

Custom allocators give you a chance to catch two classic memory bugs cheaply — bugs the C chapters already introduced you to via AddressSanitizer, but which you can now catch with a few extra bytes of your own bookkeeping, inside your own allocator, without any external tool at all.

Guard Bytes: Catching Buffer Overruns

A buffer overrun is code writing past the end of the memory it was given, corrupting whatever comes right after it. The fix: place a small fixed pattern of extra bytes (a guard, sometimes called a canary) immediately before and after every allocation's usable region. If code ever writes past its own allocation, it corrupts a guard first — and checking the guards tells you exactly that happened.

#include <cstring>

const unsigned char GUARD_PATTERN = 0xFE;
const size_t GUARD_SIZE = 4;

void* GuardedAlloc(LinearAllocator& arena, size_t sizeBytes) {
    unsigned char* mem = static_cast<unsigned char*>(
        arena.Alloc(GUARD_SIZE + sizeBytes + GUARD_SIZE));
    if (!mem) return nullptr;

    std::memset(mem, GUARD_PATTERN, GUARD_SIZE);                          // front guard
    std::memset(mem + GUARD_SIZE + sizeBytes, GUARD_PATTERN, GUARD_SIZE); // back guard

    return mem + GUARD_SIZE; // hand back a pointer to the USABLE region only
}

bool CheckGuards(void* userPtr, size_t sizeBytes) {
    unsigned char* mem = static_cast<unsigned char*>(userPtr) - GUARD_SIZE;
    for (size_t i = 0; i < GUARD_SIZE; i++) {
        if (mem[i] != GUARD_PATTERN || mem[GUARD_SIZE + sizeBytes + i] != GUARD_PATTERN) {
            return false; // something wrote past the edge of its allocation
        }
    }
    return true;
}

#include <cstdio>

int main() {
    unsigned char memory[256];
    LinearAllocator arena;
    arena.Init(memory, sizeof(memory));

    int* healthArray = static_cast<int*>(GuardedAlloc(arena, 3 * sizeof(int)));
    healthArray[0] = 100;
    healthArray[1] = 80;
    healthArray[2] = 50;

    printf("guards OK before overrun? %s\n", CheckGuards(healthArray, 3 * sizeof(int)) ? "yes" : "no");

    healthArray[3] = 999; // BUG: one element past the end -- into the back guard

    printf("guards OK after overrun?  %s\n", CheckGuards(healthArray, 3 * sizeof(int)) ? "yes" : "no");
    return 0;
}

guards OK before overrun? yes
guards OK after overrun?  no

healthArray is only 3 ints, so healthArray[3] writes 4 bytes right into the start of the back guard, overwriting part of its 0xFE 0xFE 0xFE 0xFE pattern with bytes from 999. CheckGuards notices the mismatch and returns false — catching an overrun that, without guard bytes, would have silently corrupted whatever the allocator handed out next.

Poison Patterns: Catching Use-After-Free

The other classic bug is use-after-free: reading or writing through a pointer after the memory it points to has already been freed (or, for an arena, after Reset() has handed that memory to something else). The fix: the instant memory is freed, immediately overwrite every byte of it with an obvious, unmistakable poison pattern — commonly 0xDD.

void PoisonFree(unsigned char* mem, size_t sizeBytes) {
    std::memset(mem, 0xDD, sizeBytes); // 0xDD 0xDD 0xDD ... everywhere
}

0xDD is chosen specifically because it never occurs naturally in real game data: as a 32-bit int, 0xDDDDDDDD is -573785174, as a float it's meaningless garbage, and as a pointer it's obviously not a valid address. The moment a debugger shows you 0xDDDDDDDD sitting in a variable that's supposed to be, say, a health value, you know instantly: this is freed memory, and something read it after it should have stopped.

11. Connecting to Unity: Allocator.Temp, TempJob, and Persistent

You will very rarely write a class like LinearAllocator yourself in normal Unity gameplay code — the managed heap and garbage collector from the C# chapter handle ordinary objects for you, and that's exactly why C# feels easier day to day than C++. But there is one major place in modern Unity where the ideas from this whole chapter show up directly, by name: Unity.Collections (native containers like NativeArray) and the Job System. Every native container's constructor asks you to pick an Allocator, and the three common choices map straight onto allocators you just built.

using Unity.Collections;
using UnityEngine;

public class NativeArrayDemo : MonoBehaviour
{
    void Update()
    {
        // Allocator.Temp: behaves like a StackAllocator marker taken and
        // freed right here, in this one call -- it never crosses a frame.
        NativeArray<float> scratch = new NativeArray<float>(64, Allocator.Temp);
        for (int i = 0; i < scratch.Length; i++)
        {
            scratch[i] = i * 2f;
        }
        Debug.Log("scratch[10] = " + scratch[10]);
        scratch.Dispose(); // must happen before this frame ends
    }
}

scratch[10] = 20

using Unity.Collections;
using Unity.Jobs;
using UnityEngine;

public struct DoubleJob : IJob
{
    public NativeArray<float> data;

    public void Execute()
    {
        for (int i = 0; i < data.Length; i++)
        {
            data[i] *= 2f;
        }
    }
}

public class TempJobDemo : MonoBehaviour
{
    void Start()
    {
        // Allocator.TempJob: safe to hand to a job that might not finish
        // this exact frame -- Allocator.Temp is NOT allowed to cross into
        // a job at all.
        NativeArray<float> data = new NativeArray<float>(4, Allocator.TempJob);
        data[0] = 1f; data[1] = 2f; data[2] = 3f; data[3] = 4f;

        DoubleJob job = new DoubleJob { data = data };
        JobHandle handle = job.Schedule();
        handle.Complete();

        Debug.Log("data[2] = " + data[2]);
        data.Dispose(); // we allocated it, so we must dispose it
    }
}

data[2] = 6

None of this means you should reach for a hand-written arena inside an ordinary MonoBehaviour. The managed heap and GC are the right tool for regular gameplay objects, and fighting them with your own allocator underneath would help nothing. These ideas matter the moment you're calling Unity.Collections or Job System code directly — or if you ever end up writing engine code instead of game code, in C++.

12. Glossary

• Allocator — code that manages a block of memory and hands out pieces of it, instead of calling malloc/new directly for each piece.
• Arena / linear allocator — the simplest allocator: bumps an offset forward on every Alloc, and frees everything at once with a single Reset.
• Bump pointer — the technique of moving a single offset forward to hand out the next chunk of memory, with no search involved.
• Stack allocator — a linear allocator that also supports saving a marker and rolling back to it, freeing everything allocated after that point.
• Marker — a saved offset in a stack allocator that later allocations can be rolled back to.
• LIFO — Last In, First Out: the order rule a stack allocator's markers must be freed in.
• Pool allocator — an allocator that pre-divides memory into fixed-size slots and hands them out via a free list, ideal for many same-sized objects.
• Free list — a linked chain of currently-unused blocks, often stored inside the free memory itself at no extra cost.
• Coalescing — merging two adjacent free blocks into one bigger free block when one of them is freed.
• Fragmentation — free memory scattered into gaps too small individually to satisfy a larger request, even though the total free bytes would be enough.
• Alignment — the requirement that an address be a multiple of some power of two, so the CPU (or hardware instructions like SIMD) can access it efficiently or at all.
• Padding — extra unused bytes inserted before an allocation so its start address satisfies an alignment requirement.
• Double buffering — keeping two copies of a resource and swapping which one is active each frame, so a reader (like the GPU) is never reading from the buffer currently being written.
• Guard bytes / canary — a known fixed pattern placed around an allocation to detect if code wrote past its boundaries.
• Poison pattern — a known fixed pattern written into memory the instant it's freed, so reading it afterward is obviously wrong instead of silently plausible.
• Buffer overrun — writing past the end of an allocation's usable memory, corrupting whatever memory comes after it.
• Use-after-free — reading or writing memory through a pointer after that memory has already been freed or reused.
• Allocator.Temp — Unity's per-thread, single-frame native allocator; behaves like a stack allocator marker and must be disposed the same frame.
• Allocator.TempJob — Unity's native allocator for data that must survive a few frames and can be safely passed into a scheduled Job.
• Allocator.Persistent — Unity's general-purpose, long-lived native allocator, disposed manually whenever the data is truly no longer needed.

13. Exercises

void* a = bullets.Alloc();
void* b = bullets.Alloc();

bullets.Free(a);
bullets.Free(a);   // BUG: freeing the same pointer twice

void* c = bullets.Alloc();
void* d = bullets.Alloc();
void* e = bullets.Alloc();

a = Alloc()          // pops slot0.  freeList = slot1 -> slot2 -> slot3 -> null.  a = slot0
b = Alloc()          // pops slot1.  freeList = slot2 -> slot3 -> null.          b = slot1

Free(a)              // pushes slot0 onto the front:
                      // slot0->next = (old freeList) = slot2
                      // freeList = slot0 -> slot2 -> slot3 -> null

Free(a)  // BUG, again // pushes slot0 onto the front AGAIN:
                      // slot0->next = (old freeList) = slot0   <-- itself!
                      // freeList = slot0 -> slot0 -> slot0 -> ...  (a CYCLE)
                      // slot2 and slot3 are now UNREACHABLE -- lost

That's the full toolkit: why calling malloc/new everywhere is too slow and unpredictable for a real-time game, and how fragmentation silently eats a heap even when plenty of bytes are "free." From there, four concrete allocators, each shaped around one lifetime — the arena that frees everything at once for per-frame data, the stack allocator that adds LIFO rollback with markers, the pool allocator that gives O(1) alloc/free for same-sized objects like bullets and particles, and the general-purpose free-list allocator for everything else, used sparingly. Alignment, double buffering, per-subsystem tracking, and guard bytes/poison patterns round out the toolkit real engines actually ship with. And in Unity, you'll meet exactly these ideas again the moment you touch NativeArray and the Job System — Allocator.Temp, TempJob, and Persistent are not new concepts, just new names for the allocators you just built by hand.