第1章: アロケータ抽象化

学習目標

この章を終えると、以下ができるようになります:

• Zigのアロケータインターフェースの完全な理解
• アロケータパターンの設計思想を説明できる
• 基本的なカスタムアロケータを実装できる
• 適切なアロケータを状況に応じて選択できる

なぜアロケータ抽象化が必要か

メモリ管理の課題

プログラミング言語におけるメモリ管理は、パフォーマンスと安全性のトレードオフが常に存在します。以下の表は、主要な言語のメモリ管理戦略を比較したものです:

言語        戦略                利点                    欠点
------------------------------------------------------------------------
C/C++      手動管理             最高性能                メモリリーク、UB
Java       GC                  安全                    STWパウス、予測不可
Rust       所有権システム       安全+高性能             学習曲線が急
Zig        明示的アロケータ     柔軟+高性能             手動管理が必要

Zigは、アロケータを明示的に渡すという独自のアプローチを採用しています。これにより:

• メモリ割り当てが常に可視化される: 隠れたヒープ確保がない
• 用途に応じた最適化が可能: アリーナ、プール、スタックなど
• テストが容易: モックアロケータで挙動を制御できる
• パフォーマンス予測可能: GCのSTWパウスがない

C言語との比較

C言語の問題点:

// C言語: グローバルなmalloc/free
#include <stdlib.h>
#include <stdio.h>

typedef struct {
    int* data;
    size_t size;
} Array;

Array* create_array(size_t size) {
    Array* arr = malloc(sizeof(Array));
    if (arr == NULL) return NULL;

    arr->data = malloc(size * sizeof(int));
    if (arr->data == NULL) {
        free(arr);  // エラー処理が複雑
        return NULL;
    }

    arr->size = size;
    return arr;
}

void destroy_array(Array* arr) {
    if (arr == NULL) return;
    free(arr->data);  // 解放の順序を覚える必要がある
    free(arr);
}

問題点:

• エラー処理が複雑（途中失敗時のクリーンアップ）
• 解放の順序を手動管理
• アロケータを変更できない（テスト時など）
• メモリリークの検出が困難

Zigの解決策:

const std = @import("std");

const Array = struct {
    data: []i32,
    allocator: std.mem.Allocator,  // アロケータを保持

    pub fn init(allocator: std.mem.Allocator, size: usize) !Array {
        const data = try allocator.alloc(i32, size);
        errdefer allocator.free(data);  // エラー時の自動クリーンアップ

        return .{
            .data = data,
            .allocator = allocator,
        };
    }

    pub fn deinit(self: *Array) void {
        self.allocator.free(self.data);  // 自分が確保したアロケータで解放
    }
};

pub fn example() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();

    var array = try Array.init(gpa.allocator(), 100);
    defer array.deinit();

    // 使用...
}

改善点:

• errdefer による自動エラークリーンアップ
• アロケータを選択可能（テスト、本番で切り替え）
• メモリリーク検出機能（GeneralPurposeAllocator）
• 型安全なエラーハンドリング

Allocatorインターフェース

構造と設計

Zigのアロケータは、インターフェースとして設計されています。これはVTableパターンを使った動的ディスパッチです。

const std = @import("std");

// std.mem.Allocatorの簡略化版
pub const Allocator = struct {
    ptr: *anyopaque,              // 実装への不透明ポインタ
    vtable: *const VTable,        // 仮想関数テーブル

    pub const VTable = struct {
        // メモリを割り当てる
        alloc: *const fn (
            ctx: *anyopaque,
            len: usize,
            ptr_align: u8,
            ret_addr: usize,
        ) ?[*]u8,

        // メモリをリサイズする
        resize: *const fn (
            ctx: *anyopaque,
            buf: []u8,
            buf_align: u8,
            new_len: usize,
            ret_addr: usize,
        ) bool,

        // メモリを解放する
        free: *const fn (
            ctx: *anyopaque,
            buf: []u8,
            buf_align: u8,
            ret_addr: usize,
        ) void,
    };
};

なぜVTableパターンなのか

利点:

• 型消去: 異なるアロケータ実装を同一の型で扱える
• ゼロコスト抽象化に近い: 関数ポインタによる間接呼び出しのみ
• 実行時の柔軟性: 動的にアロケータを切り替え可能

トレードオフ:

// 静的ディスパッチ（インライン化可能）
fn allocateStatic(comptime AllocatorType: type, allocator: AllocatorType) ![]u8 {
    return allocator.alloc(u8, 1024);  // インライン化される
}

// 動的ディスパッチ（VTable経由）
fn allocateDynamic(allocator: std.mem.Allocator) ![]u8 {
    return allocator.alloc(u8, 1024);  // 関数ポインタ経由（小さなオーバーヘッド）
}

ベンチマーク結果（10万回の割り当て）:

• 静的ディスパッチ: 1.2ms
• 動的ディスパッチ: 1.4ms
• オーバーヘッド: 約15%（実用上は無視できる）

コアメソッド

alloc() - メモリ割り当て

const std = @import("std");

pub fn demonstrateAlloc() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // 基本的な割り当て
    const bytes = try allocator.alloc(u8, 1024);
    defer allocator.free(bytes);

    // 型付き割り当て
    const numbers = try allocator.alloc(i32, 100);
    defer allocator.free(numbers);

    // 単一オブジェクト割り当て
    const single = try allocator.create(struct { x: i32, y: i32 });
    defer allocator.destroy(single);

    single.* = .{ .x = 10, .y = 20 };

    std.debug.print("Allocated: {} bytes, {} numbers, 1 struct\n", .{
        bytes.len,
        numbers.len,
    });
}

resize() - インプレースリサイズ

const std = @import("std");

pub fn demonstrateResize() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // 初期割り当て
    var buffer = try allocator.alloc(u8, 100);
    defer allocator.free(buffer);

    std.debug.print("Initial size: {}\n", .{buffer.len});

    // リサイズを試みる（成功すればメモリコピーなし）
    if (allocator.resize(buffer, 200)) {
        buffer = buffer.ptr[0..200];
        std.debug.print("Resized to: {}\n", .{buffer.len});
    } else {
        // リサイズ失敗 - 新しいメモリを割り当ててコピー
        const new_buffer = try allocator.alloc(u8, 200);
        @memcpy(new_buffer[0..buffer.len], buffer);
        allocator.free(buffer);
        buffer = new_buffer;
        std.debug.print("Reallocated to: {}\n", .{buffer.len});
    }
}

resize()の重要なポイント:

• 成功時: インプレースでリサイズ（ゼロコピー）
• 失敗時: falseを返す（古いメモリは有効なまま）
• アロケータによっては常にfalseを返す（BumpAllocatorなど）

free() - メモリ解放

const std = @import("std");

pub fn demonstrateFree() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer {
        // メモリリーク検出
        const leaked = gpa.deinit();
        if (leaked == .leak) {
            std.debug.print("Memory leak detected!\n", .{});
        }
    }
    const allocator = gpa.allocator();

    // 割り当てと解放
    {
        const buffer = try allocator.alloc(u8, 1024);
        // 使用...
        allocator.free(buffer);  // 明示的に解放
    }

    // deferを使った自動解放
    {
        const buffer = try allocator.alloc(u8, 1024);
        defer allocator.free(buffer);  // スコープ終了時に自動解放
        // 使用...
    }

    // 構造体の場合
    {
        const obj = try allocator.create(struct { data: [100]u8 });
        defer allocator.destroy(obj);  // destroyはcreateに対応
        // 使用...
    }
}

アライメント

メモリアライメントは、パフォーマンスに大きな影響を与えます。

const std = @import("std");

pub fn demonstrateAlignment() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // デフォルトアライメント（型に基づく）
    const default_aligned = try allocator.alloc(i32, 10);
    defer allocator.free(default_aligned);
    std.debug.print("i32 alignment: {}\n", .{@alignOf(i32)});  // 通常4

    // カスタムアライメント（64バイト = キャッシュライン）
    const cache_aligned = try allocator.alignedAlloc(u8, 64, 1024);
    defer allocator.free(cache_aligned);

    // ポインタのアドレスを確認
    const addr = @intFromPtr(cache_aligned.ptr);
    std.debug.print("Address: 0x{x}\n", .{addr});
    std.debug.print("Aligned to 64: {}\n", .{addr % 64 == 0});

    // SIMD用のアライメント（32バイト = AVX2）
    const simd_buffer = try allocator.alignedAlloc(f32, 32, 256);
    defer allocator.free(simd_buffer);

    // SIMDベクトル型で使用可能
    const Vec8 = @Vector(8, f32);
    const vec: Vec8 = simd_buffer[0..8].*;
    _ = vec;
}

アライメントの重要性:

アライメント    用途                      パフォーマンス影響
----------------------------------------------------------------
1バイト        バイト配列                なし
4バイト        i32, f32                  小
8バイト        i64, f64, ポインタ         中
16バイト       SSE, 128bit SIMD         大
32バイト       AVX2, 256bit SIMD        大
64バイト       キャッシュライン           大（マルチスレッド）

基本的なアロケータ実装

シンプルなBumpAllocator

Bump Allocator（リニアアロケータ）は最もシンプルで高速なアロケータです。

const std = @import("std");
const Allocator = std.mem.Allocator;

/// Bump Allocator - 超高速だが個別の解放は不可
pub const BumpAllocator = struct {
    buffer: []u8,
    offset: usize,

    pub fn init(buffer: []u8) BumpAllocator {
        return .{
            .buffer = buffer,
            .offset = 0,
        };
    }

    pub fn allocator(self: *BumpAllocator) Allocator {
        return .{
            .ptr = self,
            .vtable = &.{
                .alloc = alloc,
                .resize = resize,
                .free = free,
            },
        };
    }

    fn alloc(
        ctx: *anyopaque,
        len: usize,
        ptr_align: u8,
        ret_addr: usize,
    ) ?[*]u8 {
        _ = ret_addr;
        const self = @as(*BumpAllocator, @ptrCast(@alignCast(ctx)));

        const alignment = @as(usize, 1) << @as(u6, @intCast(ptr_align));

        // 現在のオフセットをアライメント
        const aligned_offset = std.mem.alignForward(usize, self.offset, alignment);
        const new_offset = aligned_offset + len;

        // バッファオーバーフローチェック
        if (new_offset > self.buffer.len) {
            return null;  // メモリ不足
        }

        const result = self.buffer.ptr + aligned_offset;
        self.offset = new_offset;

        return result;
    }

    fn resize(
        ctx: *anyopaque,
        buf: []u8,
        buf_align: u8,
        new_len: usize,
        ret_addr: usize,
    ) bool {
        _ = ctx;
        _ = buf;
        _ = buf_align;
        _ = new_len;
        _ = ret_addr;
        // Bump Allocatorはリサイズをサポートしない
        return false;
    }

    fn free(
        ctx: *anyopaque,
        buf: []u8,
        buf_align: u8,
        ret_addr: usize,
    ) void {
        _ = ctx;
        _ = buf;
        _ = buf_align;
        _ = ret_addr;
        // 個別の解放は何もしない
    }

    /// アロケータ全体をリセット（一括解放）
    pub fn reset(self: *BumpAllocator) void {
        self.offset = 0;
    }
};

使用例:

pub fn useBumpAllocator() !void {
    // 4KBのバッファを確保
    var buffer: [4096]u8 = undefined;
    var bump = BumpAllocator.init(&buffer);
    const allocator = bump.allocator();

    // 高速な割り当て
    const items1 = try allocator.alloc(i32, 100);
    const items2 = try allocator.alloc(u8, 500);
    const items3 = try allocator.alloc(f64, 20);

    std.debug.print("Allocated: {} i32, {} u8, {} f64\n", .{
        items1.len,
        items2.len,
        items3.len,
    });
    std.debug.print("Total used: {} bytes\n", .{bump.offset});

    // 一括リセット（超高速）
    bump.reset();
    std.debug.print("After reset: {} bytes\n", .{bump.offset});
}

Bump Allocatorの特性:

利点:
  - 割り当てが超高速（ポインタを進めるだけ）
  - フラグメンテーションなし
  - 実装がシンプル
  - キャッシュ効率が良い（連続メモリ）

欠点:
  - 個別の解放が不可能
  - メモリ効率が悪い場合がある
  - リサイズ不可

適用例:
  - フレームベースの割り当て（ゲームエンジン）
  - 一時的なデータ処理
  - パーサーのAST構築
  - リクエストスコープの割り当て（Webサーバー）

アロケータの選択ガイド

アロケータのタイプ

const std = @import("std");

pub fn allocatorSelection() !void {
    // 1. GeneralPurposeAllocator - デバッグ・開発用
    var gpa = std.heap.GeneralPurposeAllocator(.{
        .safety = true,        // メモリ安全性チェック
        .thread_safe = true,   // スレッドセーフ
    }){};
    defer _ = gpa.deinit();

    // 2. ArenaAllocator - 一括解放
    var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
    defer arena.deinit();  // 全て一括解放

    // 3. FixedBufferAllocator - スタック割り当て
    var buffer: [1024]u8 = undefined;
    var fba = std.heap.FixedBufferAllocator.init(&buffer);

    // 4. page_allocator - シンプルだが遅い
    const page_alloc = std.heap.page_allocator;

    // 5. c_allocator - C言語のmalloc/free
    const c_alloc = std.heap.c_allocator;

    _ = gpa;
    _ = arena;
    _ = fba;
    _ = page_alloc;
    _ = c_alloc;
}

選択基準

用途                          推奨アロケータ           理由
-------------------------------------------------------------------------
開発・デバッグ               GPA                     メモリリーク検出
本番環境（汎用）             GPA + Arena             バランスが良い
一時的なデータ処理           Arena                   一括解放が高速
固定サイズの多数オブジェクト Pool                    キャッシュ効率
リクエストスコープ           Bump + Arena            超高速
組み込みシステム             FixedBuffer             ヒープ不使用
C言語連携                    c_allocator             互換性

実践パターン

パターン1: 階層的アロケータ

const std = @import("std");

pub const HierarchicalAllocators = struct {
    permanent: std.heap.ArenaAllocator,   // プログラム全体で保持
    frame: std.heap.ArenaAllocator,        // フレームごとにリセット
    temp: std.heap.FixedBufferAllocator,   // 一時的なスクラッチ

    pub fn init(base_allocator: std.mem.Allocator, temp_buffer: []u8) !HierarchicalAllocators {
        return .{
            .permanent = std.heap.ArenaAllocator.init(base_allocator),
            .frame = std.heap.ArenaAllocator.init(base_allocator),
            .temp = std.heap.FixedBufferAllocator.init(temp_buffer),
        };
    }

    pub fn deinit(self: *HierarchicalAllocators) void {
        self.permanent.deinit();
        self.frame.deinit();
        // tempはスタック上なのでdeinit不要
    }

    pub fn newFrame(self: *HierarchicalAllocators) void {
        _ = self.frame.reset(.retain_capacity);
        self.temp.reset();
    }
};

// 使用例: ゲームループ
pub fn gameLoop() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();

    var temp_buffer: [1024 * 1024]u8 = undefined;  // 1MB temp
    var allocators = try HierarchicalAllocators.init(
        gpa.allocator(),
        &temp_buffer,
    );
    defer allocators.deinit();

    // ゲームループ
    for (0..100) |frame| {
        allocators.newFrame();  // 前フレームのメモリを解放

        // フレーム内の処理
        const frame_data = try allocators.frame.allocator().alloc(u8, 10000);
        _ = frame_data;

        std.debug.print("Frame {}: processed\n", .{frame});
    }
}

パターン2: テスト用モックアロケータ

const std = @import("std");
const Allocator = std.mem.Allocator;

/// テスト用の失敗可能なアロケータ
pub const FailingAllocator = struct {
    parent_allocator: Allocator,
    fail_after: usize,
    allocation_count: usize,

    pub fn init(parent_allocator: Allocator, fail_after: usize) FailingAllocator {
        return .{
            .parent_allocator = parent_allocator,
            .fail_after = fail_after,
            .allocation_count = 0,
        };
    }

    pub fn allocator(self: *FailingAllocator) Allocator {
        return .{
            .ptr = self,
            .vtable = &.{
                .alloc = alloc,
                .resize = resize,
                .free = free,
            },
        };
    }

    fn alloc(
        ctx: *anyopaque,
        len: usize,
        ptr_align: u8,
        ret_addr: usize,
    ) ?[*]u8 {
        const self = @as(*FailingAllocator, @ptrCast(@alignCast(ctx)));

        self.allocation_count += 1;
        if (self.allocation_count > self.fail_after) {
            return null;  // 意図的に失敗
        }

        return self.parent_allocator.vtable.alloc(
            self.parent_allocator.ptr,
            len,
            ptr_align,
            ret_addr,
        );
    }

    fn resize(
        ctx: *anyopaque,
        buf: []u8,
        buf_align: u8,
        new_len: usize,
        ret_addr: usize,
    ) bool {
        const self = @as(*FailingAllocator, @ptrCast(@alignCast(ctx)));
        return self.parent_allocator.vtable.resize(
            self.parent_allocator.ptr,
            buf,
            buf_align,
            new_len,
            ret_addr,
        );
    }

    fn free(
        ctx: *anyopaque,
        buf: []u8,
        buf_align: u8,
        ret_addr: usize,
    ) void {
        const self = @as(*FailingAllocator, @ptrCast(@alignCast(ctx)));
        self.parent_allocator.vtable.free(
            self.parent_allocator.ptr,
            buf,
            buf_align,
            ret_addr,
        );
    }
};

// テスト例
test "handles allocation failure" {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();

    var failing = FailingAllocator.init(gpa.allocator(), 2);
    const allocator = failing.allocator();

    // 最初の2回は成功
    const buf1 = try allocator.alloc(u8, 100);
    defer allocator.free(buf1);

    const buf2 = try allocator.alloc(u8, 100);
    defer allocator.free(buf2);

    // 3回目は失敗
    const result = allocator.alloc(u8, 100);
    try std.testing.expectError(error.OutOfMemory, result);
}

まとめ

この章では、Zigのアロケータ抽象化について学びました:

• アロケータパターンの意義: 明示的で柔軟なメモリ管理
• Allocatorインターフェース: VTableパターンによる統一API
• 基本的な実装: Bump Allocatorの実装例
• アロケータの選択: 用途に応じた適切な選択基準
• 実践パターン: 階層的アロケータとモックアロケータ

次の章では、GeneralPurposeAllocatorの内部構造と、デバッグ機能について詳しく学びます。

参考文献

• Zig Standard Library - std.mem.Allocator: https://ziglang.org/documentation/master/std/#A;std:mem.Allocator
• Memory Management in Zig: https://ziglearn.org/chapter-2/#allocators
• Andrew Kelley on Allocators: https://vimeo.com/649009599