メモリ安全性とオブジェクトプーリング：静的割り当てによるアプローチ

背景と問題提起

• メモリ安全性の難しさ:

  • 名前はあっても説明できない概念である「ライフタイムへの注意欠乏」が根本的な問題です。
  • 異なるバリアントを持つユニオン内でも、一つへのポインタが生きている状態のまま別のデータに属するバイトを読み込むケースが発生します。

• 過去の教訓（オーダーマッチングエンジン）:

  • リリース後の使用（use-after-free）の問題に遭遇しました。
  • キャンセルされたオーダーがプーリングされつつも、価格レベルのリンク解除が行われずメモリプールに戻されていました。
  • その結果、メモリアドレスが新しいオーダーに割り当てられ、残っているリンクの解決が続く事態となりました。

• 現在の疑問点:

  • リサイクルプーリングは「生きているオブジェクトの世代」を示すタグを持つ

    tagged union

    のように見えますが、型システム側でこれを追跡する仕組みがありません。
  • ジェネレーショナルインデックスによって問題が解決されるのか、プールケースの方が本質的に扱いやすいのか、ユニオンケースに同等の代替案が存在する ли？

オブジェクトプーリングと正しさの関係性

• 物理的型混同の危険性:

  • malloc

    /

    free

    を使用する場合、論理的な「リリース後の使用」は物理的な型混同へと変質します。
  • 同じメモリアドレスを共有している異なるオブジェクト間で、ユーザー制御可能な整数が関数ポインタとして解釈され、exploitable な脆弱性へ至る可能性があります。

• プーリングの緩和効果:

  • 「死んだ」オブジェクトリストを格納するプーリングを導入すれば、物理的な影響は異なります。
    • メモリアライアリング（参照）は発生しますが、型混同は起こりません。
    • 整数操作で関数ポインタを変更できなくなるため、安全性が向上します。
  • 例外: オブジェクト内にインライン

    enum

    を格納している場合のみ、ハードケースとして問題となります。

• 型分離されたプーリングの構築:

  • 割り当て関数を型付けし、内部で型分離されたプーリングを利用するエイリアサーを記述できます。
    • メモリ効率はやや劣りますが（異なる型間で再利用できないため）、オーバーヘッドは小さいです。
    • メモリアクセスの局所性が向上し、多くの型混同を防ぎます。
  • 注:

    Fil-C

    では C のエイリアサーインターフェースが無型化されているため適用できませんが、他の言語やライブラリでは可能です。

バグ防止のための具体的な技術

静的割り当て（Static Allocation）と定数作業（Constant Work）の 2 つのアプローチを提案します。

1. 静的割り当て（Static Allocation）

• 基本概念:

  • 初期化以降、動的メモリアロケーションを行いません。
  • システム起動時に最大オーダー数を指定し、超過は拒否します。

• 実装例:

  # コマンドライン引数で上限を指定
  $ order-engine --orders-max=1_000_000
  
  // Zig のメイン関数内での初期化
  const orders: []Order = try gpa.alloc(Order, cli_args.orders_max);
  

• 利点とリスク管理:

  • 過負荷への耐性:
    • 容量限界を超えて動作するシステムは致命的な失敗を起こします（OOM キラーによる停止やプロセスの強制終了）。
    • 起動に失敗しても、成功すれば過負荷でも適切にサービスを提供し、リソース確保が保証されます。
  • 安心感:
    • 十分なメモリがない場合は起動で失敗しますが、起動後は安定した動作が期待できます。

2. 定数作業（Constant Work）

• アプローチ A: ビットセット追跡

  const OrderPool = struct {
      orders: []Order,
      free: DynamicBitSet,
  
      fn acquire(pool: *OrderPool) ?*Order { ... }
      fn release(pool: *OrderPool, order: *Order) { ... }
  };
  

• アプローチ B: フリートリスト（フラグ付き）

  const OrderPool = struct {
      orders: []union {
          order: Order,
          next_free: ?u32,
      },
      first_free: ?u32,
  };
  

• アプローチ C: 予約済みオブジェクトの導入（推奨）

  • オダー数の限界ではなく、中立な「予約済み」オーダーを設計することで、システム内の総数を一定に保ちます。

  const Order = struct {
      id: u128,
      price: u32,
      count: u32,
      tag: enum { bid, ask, reserved },
  
      // 初期化用の定数
      pub const reserved: Order = .{
          .id = 0,
          .price = 0,
          .count = 0,
          .tag = .reserved,
      };
  };
  
  // メモリセットアップ
  @memset(orders, .reserved);
  

• メリット:

  • 認知面の改善:
    • オルダーの作成・破棄ではなく、保存則に従って循環する考え方になります。
    • 起源と行方（ライフタイム）を常に意識するため、特定の一つでも失うことが難しくなります。
  • コードの単純化と予測可能性:
    • 「生きている」オーダーのコレクションを追跡する必要がなくなります。
    • 完全なセットを反復処理し、予約済みについては何もしない（no-op）処理を行います。
    • 事前の上限指定により、最大数のオーダーがアクティブでも許容できるパフォーマンスを発揮するか保証されます。
  • パフォーマンス向上:
    • インデックスを使用せず単純に反復処理するため、コンパイラによるベクトライゼーションや CPU キャッシュによるプリフェッチが容易です。

      // 推奨：インデックスなし（高速化しやすい）
      for (orders) |order| {
          process(order)
      }
      
      // 避けるべき：インデックス経由（キャッシュミスリスクあり）
      for (orders_active) |order_index| {
          const order = orders[order_index];
          process(order);
      }
      

    • P100 レイテンシーの平坦化: 負荷に関わらず一定のパフォーマンスを保証します。

• TigerBeetle の実践例:

  • 早期返却を含む検索ループは避け、ループを自然な流れまで実行させ、一意に一致するアイテムが存在することを断言します。

    const item = for (items) |item| {
        if (predicate(item)) break item;
    } else null; // 見つからない場合は null（期待された動作）
    

結論

• 静的割り当てと定数作業は、バグ防止とパフォーマンス安定化のための強力な手法です。
• これらのテクニックはプログラミングの全てに対する普遍的な解決策ではありませんが、小規模レベルでの適用によってシステムの堅牢性を大幅に向上させます。