[P7] cc/occ/ をビルドに接続するか撤去するか決める

[thawk105]

親イシュー: #28 / 旧 #36 をコンテキストごとに分割したうちの 1 つ。

概要

occ/ は ba947f4「P3 follow-up: move occ/ under cc/」で cc/occ/ へ移動されたが、トップレベル CMakeLists.txt のプロトコル列挙 foreach(_proto cicada d2pl ermia mocc mvto oze si silo ss2pl tictoc) に occ が含まれておらず、ビルドされない宙吊り状態のまま。

現状（2026-05-14）

• cc/occ/ は存在する（K&R OCC 実装、5c74d3b で追加）。
• トップレベル CMakeLists.txt L72 の foreach に occ が無いため add_subdirectory されない。

調査結果（2026-05-15）

cc/occ/ を実際に読み込み、現在動いている cc/silo/ と対照した結果、「foreach に入れ忘れた」のではなく、そもそも現行ビルドシステムに接続できる状態に無いことが判明した。

1. 完成度 — 動くプロトコル実装ではない

• cc/occ/ のファイル: Makefile / occ.cc / transaction.cc / result.cc / util.cc / include/*.hh。
• cc/occ/ には CMakeLists.txt が無い。cc/ 配下のプロトコルで legacy な Makefile を残しているのは occ だけ（他 10 プロトコルは全て CMakeLists.txt + ccbench_add_protocol()）。
• その Makefile は include/MakefileForMasstreeUse を include しているが、このファイルはツリーに存在しない。ba947f4 の移動以前からビルドは壊れていた（コミットメッセージ自身が "the build was already broken before this move" と明記）。
• ワークロードエントリポイントは occ.cc 1 本のみ。silo のような ycsb_occ.cc / tpcc_occ.cc / bomb_occ.cc / sbomb_occ.cc の分割が無く、occ.cc 内に YCSB 専用の worker() がベタ書きされている。

2. 現行規約への適合 — 適合していない

• ccbench_add_protocol()（cmake/ProtocolHelpers.cmake）は 未使用（CMakeLists.txt 自体が無い）。
• TxExecutor クラスの名前からして違う: occ は TxnExecutor、現行規約は TxExecutor。
• API が legacy な uint64-key API。occ は void read(uint64_t key) / void write(uint64_t key)、現行 TxExecutorLike concept（include/tx_executor_concept.hh）が要求するのは Status read(Storage, string_view, TupleBody**) / update / insert / delete_record / scan×2 / commit→bool / abort。シグネチャも戻り値も別物。
• static_assert(TxExecutorLike<TxExecutor>) は当然無い（silo は transaction.hh L166 で実施）。
• ba947f4 のコミットメッセージも "It uses a plain Makefile on the legacy uint64-key API and is not wired into CMake" と現状を正確に記述している。

3. 対応ワークロード — YCSB のみ

occ.cc は makeProcedure(...) / FastZipf を使った YCSB ワークロード専用。TPC-C / BoMB には非対応。silo は ycsb / tpcc / bomb / sbomb の 4 種対応。

4. git 履歴 — 2020 年で機能更新が止まっている

commit	日付	内容
29ae0e8	2020-06-16	[occ] Copy base files for K&R OCC
7b02060	2020-06-16	[occ] Fix to run w/o concurrency control
5c74d3b	2020-06-18	[occ] Add K&R OCC implementation
7a8fe9f	2020-06-18	[occ] Add readme and masstree option etc.
ba947f4	2026-05-12	P3 follow-up: move occ/ under cc/（git mv のみ、機能変更なし）
e6abd29	2026-05-14	style: 一括 reformat（機械的整形のみ）

最後の機能的な変更は 2020-06-18。以降は移動と reformat の機械的変更だけ。foreach に入れ忘れたのではなく、ba947f4 が「接続は別 follow-up」と意図的に分離した結果がこのイシュー。

5. ビルド可否の見立て — 接続しても通らない

foreach に occ を足しても cc/occ/ には CMakeLists.txt が無いため add_subdirectory が即失敗する。仮に他プロトコル相当の CMakeLists.txt を新規に書いても、occ.cc / transaction.{hh,cc} が legacy uint64-key API のまま ccbench_common / 現行 Procedure / TupleBody 等とリンクするので コンパイル・リンクは通らない。接続には実質「現行 API への移植」（TxExecutor 化、ycsb_occ.cc 等への分割、concept 適合）が必要で、これは新規プロトコル追加とほぼ同等の作業量。

6. 重複・冗長性 — silo と被る

occ（K&R OCC）は OCC 系プロトコルだが、cc/silo/ も OCC 系であり、こちらは現行 API・4 ワークロード対応・concept 適合済みで完全に wired。OCC 系の研究上の代表は silo が担えている。occ 固有の研究的価値（K&R オリジナルの read/validation/write フェーズ分離）はあるが、現状の壊れた legacy 実装のまま維持するコストに見合わない。必要になれば 2020 年の実装を git 履歴から復元して現行 API で書き直せる。

推奨: 撤去

理由:

1. 接続コストが新規実装並み — CMakeLists.txt 新規作成 + legacy uint64-key API → 現行 TxExecutorLike への全面移植 + ワークロードエントリポイント分割 + concept 適合。「入れ忘れを直す」レベルではない。
2. 6 年間機能更新なし — 2020-06-18 以降メンテされておらず、ba947f4 移動時点で既にビルド不能だった。
3. silo と研究領域が重複 — OCC 系の代表は現行 API 適合済みの silo が担えている。
4. 撤去の損失は小さく可逆 — K&R OCC の実装は git 履歴（5c74d3b〜7a8fe9f）に残るので、将来必要になれば復元して現行 API で書き直せる。
5. CLAUDE.md のハードルール「ツリーにあるがビルドされない中途半端な状態を残さない」に照らし、撤去が最短で状態を解消する。

やること（方針: 撤去）

• cc/occ/ ディレクトリを削除する（git rm -r cc/occ）。
• CLAUDE.md / CLAUDE_en.md、docs/protocols_ja.md / docs/protocols_en.md から cc/occ/ への参照を削除する（_ja / _en セット更新の Hard rule に従う）。
• トップレベル CMakeLists.txt の foreach は変更不要（元から occ を含まないため）。コメント等で occ に触れている箇所があれば併せて削除。
• 削除の理由（本イシューの調査結果）をコミットメッセージに記録し、本イシューにリンクする。

完了条件

• cc/occ/ が撤去され、「ツリーにあるがビルドされない」中途半端な状態が解消されていること。
• docs / CLAUDE 系から cc/occ/ への dangling な参照が残っていないこと（_ja / _en 両方）。
• 撤去の判断と理由が記録されていること（本イシュー + コミットメッセージ）。