explicit lock の導入

1. explicit lock の導入 平成１４年４月２日

2. 概要 • イナダのシステム領域（heap header, object entry area）は自動的に explicit lock が行われる • データ領域は explicit lock と implicit lock の混在も，explicit lock のみも許す． • explicit lock のためのシグナルハンドラとメモリプロテクション書き換え（リード／ライト別）を行った

3. いなだのヒープ構造 ・ヒープ内の空き 情報など heap header システム領域 ・タイプ番号 ・OID からオフセット への変換 object entry area データ領域 object area オブジェクト

4. システム領域は，イナダのオペレーション実行時にアクセスされるシステム領域は，イナダのオペレーション実行時にアクセスされる イナダのオペレーション OIDによる操作 object creation object deletion データベースオープン 　　→　implicit lock を使わずに，イナダのオペレーション（メソッド）の中で　explicit lock する　（メソッドの書き換え）

5. いなだのヒープ構造

6. Implicit lock と Explicit lock Implicit lock Explicit lock ページフォールトシグナル ページロック用メソッド ページロック済み ならば ワカシへページロック要求 「配列」を調べる メモリプロテクション書き換え ワカシへページロック要求 ページロックモードを 「配列」に記録 ページロックモードを 「配列」に記録 ユーザはページロックを意識しない ユーザはページロックを意識する （赤字はシステムコール）

7. 課題 • いなだのシステム領域について，本当に，explicit lock が可能か • object entry area →　可能 OID を使った操作，object creation, object deletion 時にのみアクセスされる領域であるから • heap header →　可能

8. 課題 • ユーザがexplicit lock を望まないことがありえる • 最初は implicit lock で実装し，高速化したくなったら，explicit lock に書き換えることがありえる 　→ 「explicit lock と implicit lock の混在」によって，ページロックのかけ忘れを検出したい • implicit lock だけの場合よりも，「explicit lock と implicit lock の混在」の方が性能が良い • イナダの実装上，「explicit lock と implicit lock の混在」があれば便利　 • object creation, object deletion 時以外にもアクセスがありえる． • object creation, object deletion 部分に explicit lock と implicit lock を埋め込むことは容易．それ以外の部分も可能だが、場所が多い（面倒） • 「explicit lock と implicit lock の混在」によって，ページロックのかけ忘れを検出したい

9. Implicit lock と Explicit lockの混在 (2) や(イ)も 考える

10. implicit lock と　explicit lock　の混在

11. 「Implicit lock と Explicit lockの混在」を導入する理由 • Heap Header, Object Area での「ページロックのかけ忘れ」, 「ページロックのかけ間違い」を検出するためのツールとして • テスト実行モードでは，ロックのかけ忘れ、かけ間違いのヒープ番号、ページ番号、メモリアドレス，オブジェクトIDを表示 • 最初は implicit lock を使い，性能向上の必要に応じて explicit lock を使う • Explicit lock, implicit lock はヒープオープン時に設定可能

12. Implicit lock と Explicit lockの混在 Implicit lock と　Explicit lock　混在 Implicit lock ページフォールトシグナル ページフォールトシグナル ページロック用メソッド ワカシへページロック要求 ページロック済み 「配列」を調べる メモリプロテクション書き換え ワカシへページロック要求 ページロックモードを 「配列」に記録 メモリプロテクション書き換え ページロックモードを 「配列」に記録 （赤字はシステムコール）

13. ページ境界 • implicit lock 時 • アクセスをページ単位で検出 • アクセスされたページのみのロック • explicit lock 時 • オブジェクトを含むページ（複数でありえる）のロック

14. Implicit lock と Explicit lockの混在によるオーバーヘッド ページフォールトシグナル ページロック用メソッド ページロック済み implicit lock だけの 場合より増える部分 「配列」を調べる ワカシへページロック要求 explicit lock だけの 場合より増える部分 メモリプロテクション書き換え ページロックモードを 「配列」に記録 （赤字はシステムコール）

15. 予備的実験の途中報告 • TPC-C ベンチマーク • ハードウエア kei • 設定：　MPL=1 での性能 • 目的： implicit lock と explicit lock 混在で 　（つまり、わざわざ explicit lock を導入しなくても）　どれほど性能が上がりそうかを見たい

16. implicit lock と　explicit lock　の混在 explicit lock に変更された もの リードロック数： 11441 ライトロック数： 45985 リードロック数： 21517 ライトロック数： 16723

17. 性能値 MQTH: 1970 New Order 1970 Payment 1904 Order Status 191 Delivery 192 Stock 183 implicit lock にしていたところを explicit lock に変えた効果はあった

18. 「予備的実験」の実験結果から示唆されること「予備的実験」の実験結果から示唆されること • explicit lock と implicit lock の混在を止めるべき部分 (1) Object Area について • object creation 時も explicit lock を行うようにイナダを書き換えるべき (2) Object entry area • ＴＰＣ－Ｃプログラムの explicit lock の実装が手抜き（ユーザが手動でロック）なので，自動でロックされるようにイナダを書き換えるべき • Heap Header についてはexplicit lock を行うべき