進捗 Javaバイトコード変換による 細粒度CPU資源管理 hayami 2018/11/8
本研究の概要 Javaプログラムの消費資源を細粒度に管理 バイトコード変換による実装 実行命令数を正確にカウント カウントをもとに何かおもしろいことをする(未定) バイトコード変換による実装 移植性、柔軟性はよい Time overheadが大きい (11~45%) 2018/11/8
Overheadをどうするか? バイトコード変換アルゴリズムの改良 実装の改良 Trivial: 1命令ずつカウント EachBlock: 基本ブロック単位でカウント WeightFirst: 基本ブロックの重みを利用 実装の改良 高速なthead local シグニチャ書換 2018/11/8
目次 概要 バイトコード変換アルゴリズム 実装 まとめ･ToDo 2018/11/8
バイトコード変換アルゴリズム (review) 2018/11/8
変換アルゴリズム 入力 出力 対象プログラム 制約*を満たすコードの挿入位置 各ポイントでいくつカウンタを増加するか 2018/11/8 変換アルゴリズム 入力 対象プログラム 出力 制約*を満たすコードの挿入位置 各ポイントでいくつカウンタを増加するか *正確なカウント＆Lmax制約 (後述) 2018/11/8
アルゴリズム適用例 入力例 出力例1: Trivial 出力例２: EachBlock 出力例3: WeightFirst ← +1 Method void main(java.lang.String[]) iconst_0 istore_0 goto 36 iinc 0 1 iload_0 ldc #31 <Integer 100> if_icmplt 9 return ← +1 ← +1 ← +1 ← +3 ← +3 ← +1 ← +1 ← +4 ← +1 ← +1 ← +1 ← +3 ← +1 ← +1 ← +4 出力例1: Trivial 出力例２: EachBlock 出力例3: WeightFirst 2018/11/8
変換アルゴリズムへの要求 実行命令数の正確なカウント 実行時のオーバーヘッド小 Lmax制約 1命令おきにコード挿入は非現実的 ある程度まとめてカウンタをインクリメントするべき Lmax制約 ：カウンタの値と正確なカウントとの誤差 ：「きめ」に関する定数 2018/11/8
EachBlock 基本ブロックの末尾でまとめて増加 +3 +1 2018/11/8
WeightFirst 基本ブロックを実行頻度に応じて重み付け 重いブロック優先 +3 +4 +4 重いブロック 2018/11/8
実装の改良 2018/11/8
Thread Localな変数 各threadの実行命令数をカウント Java.lang.ThreadLocal 非常に高コスト currentThread() invocation + Table lookup 2018/11/8
java.lang.Theadの書き換え フィールドの追加 Table lookupは不要 (ただのフィールド参照) public class java.lang.Thread { CPURes cpures; private void init(…) { cpures = new CPURes(); … } // フィールドの追加 // インスタンスの生成時に // フィールドも初期化 2018/11/8
シグニチャの書換(引数+1) CPUResを引数で渡す currentThread()も、Table lookupも不要 void a() { b(); } void A(CPURes res) { b(res); } 2018/11/8
実験 実行時間の計測 シグニチャ書換の影響 アルゴリズムの比較 Signature Unmodified: シグニチャ書換前 Signature Modified: シグニチャ書換後 アルゴリズムの比較 Eachblock v.s. WeightFirst 2018/11/8
1. 実行時間 (シグニチャ書換前後) シグニチャの書換で実行時間が改善 (2~10倍 → 1.x倍) 2018/11/8
2. 実行時間 (EB v.s. WF) WFでもあまり改善は見られない 2018/11/8
まとめ バイトコード変換による実装は一段落 変換アルゴリズム WeightFirstでは物足りない 2018/11/8
ToDo Brute Forceで最適解を求めてみる 「おもしろいこと」とは何か? 2018/11/8