[論文レビュー] Don't sit on the fence: A static analysis approach to automatic fence insertion

Jade Alglave, Daniel Kroening+2 more|arXiv (Cornell University)|Dec 5, 2013

Parallel Computing and Optimization Techniques被引用数 39

ひとこと要約

本稿では、x86-TSO、Power、ARMなどの弱いメモリアーキテクチャ上で順序整合性（SC）を保証するために、自動的にメモリフェンスを挿入する静的解析ツール musketeer を提示する。抽象化された実行グラフにおける臨界サイクルの検出に公理的意味論を用いることで、高い精度とスケーラビリティを達成し、memcached（10,000 LoC）を含む大規模なコードベースを、既存のツールと比較して最小限のパフォーマンスオーバーヘッドで解析可能である。

ABSTRACT

Modern architectures rely on memory fences to prevent undesired weakenings of memory consistency. As the fences' semantics may be subtle, the automation of their placement is highly desirable. But precise methods for restoring consistency do not scale to deployed systems code. We choose to trade some precision for genuine scalability: our technique is suitable for large code bases. We implement it in our new musketeer tool, and detail experiments on more than 350 executables of packages found in Debian Linux 7.1, e.g. memcached (about 10000 LoC).

研究の動機と目的

• 弱いメモリアーキテクチャ上で実行される並行プログラムにおける手動でのメモリフェンス挿入の課題に取り組むこと。これは誤りを起こしやすく、アーキテクチャ依存である。
• 動的またはインタリーブベースの手法が引き起こす状態空間の爆発を回避するスケーラブルなフェンス挿入の解決策を開発すること。
• プログラム実行における臨界サイクルの正確な検出を通じて、順序整合性（SC）を強制することで正しさを保証すること。
• 実世界のコードベース（memcached や liblfds データ構造）における、さまざまなフェンス挿入戦略のパフォーランスへの影響を評価すること。
• 複数のアーキテクチャにまたがる既存のフェンス挿入技術を統一的に比較するフレームワークを提供すること。

提案手法

• 本手法は、[AMSS10] における公理的意味論を用いて弱いメモリ動作をモデル化し、順序整合性の最小違反として臨界サイクルを定義する。
• すべての可能なプログラム実行を過剰近似する抽象実行グラフ（aeg）を構築することで、潜在的なデータ競合の静的解析を可能にする。
• aeg における依存関係およびデータ／制御フローの分析により、臨界サイクルを検出する。フェンスが挿入されない場合にSCが破られるポイントを特定する。
• サイクルに影響を受ける場所にフェンスを挿入することでサイクルを解消し、SC を回復させる。アーキテクチャ固有のフェンスタイプ（例：x86 では mfence、ARM では dmb、Power では sync）を用いる。
• 本アプローチは x86-TSO、Power、ARM などの複数のアーキテクチャをサポートし、フェンスの数だけでなく、フェンスタイプ間のコスト差異も考慮する。
• ツール musketeer はこの手法を実装し、374 個の Debian Linux 7.1 実行可能ファイルを含む実世界のコードベースと統合する。

実験結果

リサーチクエスチョン

• RQ1 静的解析アプローチとして、memcached（10,000 LoC）を含む大規模で実世界のコードベースにスケーラブルに適用できるか。また、フェンス挿入の精度は高いままであるか？
• RQ2 musketeer のフェンス挿入のパフォーマンスオーバーヘッドは、各メモリアクセスの後にフェンスを挿入するようなナイーブな戦略と比較してどうか？
• RQ3 musketeer は、pensieve や Visual Studio 2013、dfence といった既存のツールと比較して、フェンス数と実行時間の両面で優れているか？
• RQ4 さまざまなフェンス挿入戦略が、スタックやキューのような並行データ構造における実行時パフォーマンスに及ぼす影響はどの程度か？
• RQ5 完全な動的探索なしに、公理的意味論モデルを用いて臨界サイクルを効果的に検出できるか？

主な発見

• musketeer は、memcached（9,944 LoC）を含む 374 個の実世界の Debian 実行可能ファイルを解析した。TSO ではフェンス挿入に 13.9 秒、Power では 89.9 秒を要した。
• memcached では、TSO でたった 3 つのフェンス、Power では 70 つのフェンスを挿入した。これは (e) や (h) のようなナイーブな戦略と比較して顕著に少ない。
• musketeer でフェンス挿入された memcached の実行時オーバーヘッドは、すべての SC を保証する戦略の中で最も低く、x86 では平均 0.6%、ARM では 0.2% であった。
• liblfds のスタックおよびキューベンチマークでは、musketeer のオーバーヘッドは x86 で 0.6%、ARM で 0.2% であり、pensieve（3.2% および 5.8%）や Visual Studio（1.5% および 4.2%）を上回った。
• ptunnel（aeg に 1,867 ノード）のような複雑なプログラムにもスケーラブルに適用可能であったが、サイクル爆発のため Power ではタイムアウトが発生した。これは極めて複雑なケースにおける限界を示している。
• musketeer のフェンス挿入は、静的手法の中で最も正確であり、同じベンチマークで動的ツールの dfence よりも速度とフェンス数の両面で優れていた。