1

Java バイトコード変換による

細粒度 CPU 資源管理~Progress Report for SWoPP2001~

hayami

2

背景

Java の普及・用途の多様化アプレット

信頼できないコードも安全に実行したいSecurity Manager, Verifier…CPU 、メモリといった資源の管理が不充

分 悪意のあるプログラムが資源を独占する可能性がある

3

本研究の目的

ユーザレベルで CPU 資源を管理

Management = Accounting + Restriction*Accounting

プログラム毎に CPU 資源の消費量を計測Restriction

資源を独占しているプログラムに対処

* ” + Reservation” も考えられる

4

発表の概要

アプローチ問題の定式化アルゴリズムの提案実装・実験関連研究卒論からの進展・ TODO

今後の予定

5

アプローチJVM を改変命令を実行しながら直接資源を管理

直接的

OS の機能を利用native code を使用して OS の資源管理機能を利

用特定の OS に限定される。ポータビリティが悪い

バイトコード変換資源管理を適用する対象プログラムを変換

既存のどの JVM でも動作JIT(Just in Time Compiler) の恩恵にあずかれる柔軟性が高いただし、実行時のオーバーヘッドは比較的大きい

6

バイトコード変換例class NullLoop{ public static void main(String[] args) { for (int i=0; i<100; i++) ; }}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

ソース

バイトコード

CPURes.incrementAndCheck(3)

iconst_3invokestatic #34 <Method incrementAndCheck(int)>

7

変換を行う際の方針

プログラム中に適切なコードを挿入、実行命令数を動的にカウントオーバーヘッドは小さく

1 命令ずつカウントしていては話にならない管理のきめ細かさを保証

カウンタの値と実際のカウントがあまりに乖離するのは不都合

カウントは正確に

8

対象プログラムのモデル化~ コード挿入コストの定義 ~Control Flow Graph(CFG) でモデル化 Basic Block → Node 制御の移動 → Edge Block の実行頻度 → 重み

iconst_0istore_0goto 8

iinc 0 1

iload_0ldc #1 <Integer 100>if_icmplt 5

return

コード挿入コスト Ctotal

= （コードを挿入した Node の重みの総和 重複を許す）

1

100

101

1

9

高々 Lmax 命令以内に、少なくとも１回はインクリメントされることを保証

e.g. Lmax 制約はループ中に最低 1 つはコードを挿入することを要請

「きめ」に関する制約条件~Lmax 制約 ~

　　　： インクリメントｆｒｅｅの間隔　　　：「きめ」に関する定数

　　　： インクリメントｆｒｅｅの間隔　　　：「きめ」に関する定数

maxL

maxL

10

問題の定式化 (1)

入力 : CFG 重み

出力 : Lmax 制約を満たし、かつ実行命令数を正確

にカウントするようなコード挿入のうち、コスト Ctotal を最小にするようなもの

),( EVG は自然数vv wVvw ,

11

問題の定式化 (2)

新たに 2|V| 個の変数を導入vin: v の先頭における真のカウントとのズレ

vout: v の末尾における真のカウントとのズレ

cv: vin,vout から一意に定まる部分コスト

):(,max

の長さvlL

vlvwc v

outvinvv

整数 outinoutin vvLvv ,,,0 max

1

4

2

3

1in

1out…

12

問題の定式化 (3)

「 Edge にはコードを挿入しない」条件(VFreq(G,vpl))

のもと、全体のコスト

を最小化せよ

),( outinVv

vtotal vvcC

Espsp inout ),(,

13

変換アルゴリズム ( 案 )

1. 全探索で厳密解を求める2. wv の大きいところから決めていく3. いくつかの制約を緩和して近似4. EachBlock

∀vin,vout = 0 とする

Vv

i

Vvveach L

lcC

max

)0,0(

14

例題

問題 :　 　 Lmax=10, 1in=0

v(lv,wv)

1(5,1)

4(5,1)

2(5,101)

3(1,100)

制約 :　 1in=0 2in=1out=3out

3in=2out=4in

0 1≦ in,1out,…,4in,4out<Lmaxの下、 Ctotal を最小にするような整数1in,1out,…,4in,4out を計算せよ

※解が求まれば最適なコードの 挿入位置は簡単に決定できる

15

EachBlock

各ブロックの末尾に挿入 1in=1out=,…,=4in=4out=0 は制

約を満たすが最適解ではない

Ctotal = 1+101+100+1

= 203

問題 :　 　 Lmax=10, 1in=0

v(lv,wv)

1(5,1)

4(5,1)

2(5,101)

3(1,100)

16

wv の大きいところから決めていく重み最大のノードから決定

1. 2in=0 (→1out=3out=0)

2. 2out=5(→4in=3in=5) Ctotal = 1+100+1

= 102

最適解と一致

問題 :　 　 Lmax=10, 1in=0

v(lv,wv)

1(5,1)

4(5,1)

2(5,101)

3(1,100)

17

実装

JOIE( バイトコード変換ツール ) を利用Pure Javaクラスローダの機能を利用しロード時に変

換

使い方

e.g.

> Java Main –a プログラム名 arg1　arg2 …

> Java Main –a Hello

18

実験クラスロード時間と総実行時間を計測 -classic と -hotspot の 2通り

アルゴリズム Each Block(他のアルゴリズムは未実装 )

環境 K6-2 450MHz, mem 128M, Win98, Java2 SDK1.3

•Fib: Naïve な再帰で fib(35) を計算•Linpack: float のベンチマーク•Caffeine: sieve, loop, logic, string, float, method…•Raytrace: レイトレ (Frame版 )•JLex: A Lexical Analyzer Generator for Java

19

実験結果 (classic)

#class 挿入前 (msec) 挿入後 (msec)

Load Total Load Total

Fib 1 440 16,800 550 51,410

Linpack 1 530 1,040 750 1,790

Caffeine 11 570 24,180 1,710 26,240

RayTrace 17 660 275,230 2,140 383,600

JLex 24 680 2,660 4,480 7,700

20

実験結果 (HotSpot)

#class 挿入前 (msec) 挿入後 (msec)

Load Total Load Total

Fib 1 480 1,650 550 2,860

Linpack 1 470 660 770 970

Caffeine 11 510 19,220 1,720 21,500

RayTrace 17 890 55,400 2,400 71,500

JLex 24 650 1,580 3,300 4,580

21

関連研究

資源管理Jres[Czajkowski,Eicken 98]

コード挿入アルゴリズムPunctual Polling[田中 01]

バイトコード変換ツールJOIE[Cohen,Chase 98]

22

卒論後の進展

使い勝手の向上クラスローダを利用して実行時に変換

コード挿入アルゴリズムの改良ノードの重みを考慮実行命令数の正確なカウント

より詳しい性能評価さまざまなベンチマークで実験・評価

23

TODO

コストの最小化が NP完全であることの証明流量保存則を満たすグラフに限定しても NP完全か ?

アルゴリズム拡張

Intraprocedural → Interprocedural ループ展開

実装現在“ java” で始まるパッケージには変換を不適用 ( ク

ラスローダに関する制約 )簡単な最適化 ( メソッド呼出で increment は酷い )

名前がほしい

24

今後の日程

6/13(水 ) 本日

7/3 (火 ) 論文提出締め切り

7/25(水 ) ~ 27(金 ) SWoPP@ おきなわ

25

To　be　continued...