[構造監査] 新CCプロトコルを安全・低コストに追加できるよう基盤をリファクタリングする

[thawk105]

背景・動機

CCBenchの使命は「共通基盤の上でCCプロトコルを比較する」ことだが、VLDB 2020リリース以降の累積的なドリフトにより、新しいCCプロトコルを追加するコストが不必要に高くなっている。また、誤った実装を持つプロトコルを追加しても、分離レベルの正当性を検証する仕組みがどこにも存在しないため、バグが検出されない。

このイシューは構造的な問題の監査結果をまとめ、「新CCプロトコルを安全・低コストに追加できる」目標に向けた優先順位付き改善提案を記録するものである。

発見された問題

1. ビルドの重複がccacheで隠蔽されている

各プロトコルの CMakeLists.txt が file(GLOB) を使って同一ソースを繰り返し列挙しており、10プロトコル×28バイナリ分が個別にコンパイルされる。ccacheが構造問題をマスクしているだけで、add_library(ccbench_common STATIC ...) で根本解決できる。

その他のCMake衛生問題:

• add_definitions(...): 非推奨（3.12以降）が182箇所
• file(GLOB) によるソース列挙（変更でreconfigureが走らない）
• masstree/mimalloc がrawパスでリンクされており、importedターゲット化されていない
• silo/, ss2pl/, cicada/, mocc/, ermia/ の CMakeLists.txt が CRLF 改行

2. 「共通」コードが実際には共通化されていない

result.cc が10プロトコルに存在し、違いはグローバル変数名（SiloResult, CicadaResult など）のみ。util.cc も大部分が重複。ワークロードエントリポイントもスレッド生成・バリア・集計ロジックがほぼ同一。

3. TxExecutorコントラクトがコードではなくCLAUDE.mdに書かれている

CLAUDE.mdには各プロトコルの TxExecutor が実装すべきAPIが記載されているが、abstractクラスも、C++20 concept も、static_assert もなく、契約が強制されない。過去には scan(..., int64_t limit) 未実装でTPC-Cのランタイムクラッシュ、Status::WARN_NOT_FOUND 時の未初期化ポインタ参照など、コンパイル時に検出できたはずのバグが実際に発生している。

4. ツリー内のデッドコード

対象	状況
occ/	ツリー内に存在するが add_subdirectory されていない
#add_subdirectory(tpcc_silo)	トップレベルCMakeのコメント行（ディレクトリは既に削除済み）
bootstrap_tbb.sh	third_party/tbb はサブモジュールにも存在しない
third_party/spdlog	include/logger.h を定義するが、その #include は0件
instruction/	独自Makefileのマイクロベンチ。CMakeに未接続
common/Makefile, include/Makefile	CMake移行前の残骸
cc_format/	新プロトコルのテンプレートだがMakefileベースでCMakeと乖離
ss2pl/test/CMakeLists.txt	add_subdirectory(test) されていない孤立テスト

5. テストインフラが機能していない

• トップレベル CMakeLists.txt に enable_testing() なし
• CIに ctest ステップなし（コンパイル確認のみ）
• googletestはサブモジュールとして存在するが、上記の孤立テスト以外に使われていない
• include/ 共通コンポーネント（atomic_wrapper, rwlock, zipf等）のユニットテストがない
• 「Snapshot Isolation」「直列化可能」と主張するプロトコルを追加しても、その主張を検証するものがない

6. 新プロトコル追加の手順が劣悪

cc_format/README.md には行番号ベースの編集指示が書かれており、内部リファクタリングのたびに無効化される。また cc_format/ 自体がMakefileベースで本体CMakeビルドと断絶しており、マルチバージョン/決定論的スタイルはスコープ外。

7. プロトコル×ワークロードの対応表が非宣言的

README.md / docs/protocols.md / CLAUDE.md の3箇所を人手で同期する必要があり、単一の信頼できるソースがない。

改善提案（ROI順）

本イシューは以下のサブイシューに分割して管理する:

• [P0] common/ を静的ライブラリ化する #30 P0: common/ を静的ライブラリ化する
• [P1] TxExecutorコントラクトをC++20 conceptで明示する #31 P1: TxExecutorコントラクトをC++20 conceptで明示する
• [P2] per-protocolボイラープレートを共通化する #33 P2: per-protocolボイラープレートを共通化する
• [P3] 宣言的CMake関数 ccbench_add_protocol() を導入する #32 P3: 宣言的CMake関数 ccbench_add_protocol() を導入する
• [P4+P8+P10] CMake衛生一括対応（オプション集約・FetchContent・フォーマット） #37 P4+P8+P10: CMake衛生（オプション集約・FetchContent・フォーマット）
• [P5] cc_format/ を削除しプロトコルスケルトン生成スクリプトに置き換える #34 P5: cc_format/ を削除しプロトコル生成スクリプトに置き換える
• [P6] テストインフラを機能させる + 分離レベル正当性を椚認するテストを追加する #35 P6: テストインフラを機能させる＋分離レベルチェッカーを追加する
• [P7] デッドコード・残骸ファイルを一掃する #36 P7: デッドコードを一掃する
• [P9] 構造化ベンチ出力とマトリクス実行スクリプトを追加する #38 P9: 構造化ベンチ出力とマトリクス実行スクリプト

依存関係

P0 (#30, common lib)
├── P3 (#32, declarative CMake)  ←── P4/P8/P10 (#37, 衛生, 並行可)
│   └── P2 (#33, boilerplate統合)
│       └── P5 (#34, generator)
└── P1 (#31, TxExecutor concept)
    └── P6 (#35, isolation checker)

P7 (#36, dead code)    ← いつでも可
P9 (#38, bench output) ← いつでも可

PoC 推奨スコープ

silo/ 1プロトコルに対して P0 + P1 + P3 を適用してPoC作成。期待される成果:

• silo/CMakeLists.txt が ~100行 → 10〜20行に削減
• silo/result.cc と silo/*_silo.cc のボイラープレートが大幅削減
• TxExecutorLike conceptが limit overload系のバグをコンパイル時に検出

成功すれば残り9プロトコルへ展開する。

[thawk105]

#28 の duplicate。こちらは間違えて作成した重複イシューなのでクローズする。サブイシュー (#30〜#38) は #28 に紐付け直した。

[thawk105]

サブイシュー再編: #34（P5: cc_format/ 削除 + プロトコル生成スクリプト）をクローズし、#36（P7: デッドコード一掃）に統合した。scripts/new_protocol.py によるスケルトン生成は AI スキャフォルディングで代替可能なため廃止。cc_format/ 削除と新プロトコル追加手順の概念ベース文書化は #36 のチェックリストに移管済み。