スライド 1

Transcription

1 プログラミング言語処理系論 (8) Design and Implementation of Programming Language Processors 佐藤周行 ( 情報基盤センター / 電気系専攻融合情報学コース )

2 今日の予定 VM 設計の実際 ( 前回とすこし被る ) Stack Machine vs. Register Machine 命令セットアーキテクチャ ターゲットとなるプログラミング言語を効率よく実行するために JVM のデザイン

3 Stack Machine vs. Register Machine Stack Machine 各種演算 (load/store, arithmetic, ) のオペランドにスタックを想定する スタックに プッシュする ポップする 演算が explicit/implicit にある フレームなど スタックで効率よく実装できるものが多くある コードが簡潔になる場合が多い

4 Register Machine Register Machine 各種演算のオペランドにレジスタ ( 変数 ) を想定する ハードウェア命令との親和性が高いと主張する ハードウェアとの親和性を考えるとき 命令体系のレジスタセットとハードウェアのレジスタセットが異なる場合 Register Allocation が必要になる レジスタの選択の自由度が上がる分 コードは一般に複雑

5 喧嘩は往々にして起こるもので ( 問題 10) 以下の論文を読んで概要をまとめよ Y. Shi, K. Casey, M. A. Ertl, D. Gregg: Virtual Machine Showdown: Stack Versus Registers, ACM Transactions on Architecture and Code Optimization, r(4), 2008.

6 では Java VM をみてみましょう

7 命令セットアーキテクチャ (ISA) VM で扱うデータの型について 対象となる言語によって若干違い 命令をデザインする時に必要 JAVA VM byte/char/short/int/long float/double boolean/return address reference (class/array/interface)

8 実際に見てみる ISA は VM の思想を理解する上で重要 Java の場合は javap を使う 今回は javap で遊んでみる javap c 逆アセンブル やれることは 前回アセンブリコードを出力したのとほぼ同じ

9 言語的に重要なもの オブジェクトの生成 new 関数 ( メソッド ) コール フレームの構築 invokevirtual invokestatic invokespecial invokedynamic

10 VM として考える必要のあるもの メモリ管理 コード領域 定数領域 ヒープ領域 ローカル環境 ( フレーム ) 領域

11 JAVA VM Heap Thread PC Thread PC VM stack VM stack frame Method Area Heap text Segment Class instance arrays Incl. Runtime Constant pool frame 11

12 JVM のメモリ管理 JVM Spec 2.5 Runtime Data Areas PC Register (per thread) JVM Stacks 通常のマシンのスタックに相当する 定義がアブストラクトなため いろいろな実装が可能 操作は push/pop 及び 演算系 ふつうは フレーム ローカル変数 リターンを格納する フレームの扱いはすぐ後で

13 JVM のメモリ管理 (cont d) Heap Class Instance Array Memory 管理はGCで行う Objects are never explicitly deallocated Method Area Per class structure

14 JVM のメモリ管理 (cont d) Run-Time Constant Pool Per class/interface runtime representation of the constant_pool table. Constants Method and field references (Will be resolved at run-time Class/Interface が JVM によって作成されるごとに作成される Native Method Stacks

15 Native な環境でのプログラム実行に用意されている概念はだいたい用意されている PC <-> PC Stack <-> Stack Heap <-> Heap (with GC) Text Segment <-> Method Area Symbol Table + RODATA <-> Runtime Constant Pool

16 Runtime Constant Pool のアクセス ldc (load constant) でアクセスする 小さい定数は コードの中に直接埋め込むことができる 大きい定数や文字列は Constant Pool に格納していちいちロードするしかない シンボルは ( 数字も含めて ) コンパイル時に resolve されている

17 Control について Exception Handling 以下のプログラムを見てみる class c_a_t { double throwone(int i, int j) throws ArithmeticException { return i/j; } void catchone(int i) { try { throwone(3,i); } catch (ArithmeticException e) { throwone(3, i+1); } } }

18 Exception Table の管理 Class file を作る時に Exception Table に関する属性が決められる from to target type Class java/lang/arith (0 PC<7 の時に例外が発生したら 10 に跳べ )

19 Native な環境での例外 OS の腕の見せ所 シグナルに関する C interface が用意されているのが普通

20 Concurrenty への対応 Synchronized Monitor の導入 特別な Exception の対応 では 以下のコードを見てみましょう class sync { void onlyme() { synchronized(this) { System.out.println("abc"); } } }

21 クラスファイルの管理 クラスファイルのロード 実は Class として用意されていて Java.lang.ClassLoader getsystemclassloader getclassloader ファイルからのロード ネットからのロードその他に対応

22 フレームの管理 フレームの大きさはコンパイル時に決定する SP や BP のセット等は Invoke 時になされる 引数はどう渡されるのか? *load, *store でアクセスできる local variable に引数が渡される Local variable は フレームの一部であるが スタック上に作る必要はない!? ヒープに local variable を作ってもよい (JVM のデザインの問題 )

23 フレームに格納されるデータ リターンアドレス (*returnで使用) local variable (*load/*storeで使用) Exception Table

24 コンパイルしてみる class x { static int content; x(int y) { content = y; } public int get_content() { return content; } public void addxx(x x1) { int y; フレーム0 フレーム1 フレーム2 フレーム3 フレーム this 第一引数第二引数第三引数 0 } } y = x1.get_content(); content += y; iload_n, aload_n, istore_n, aload_n 等の命令がフレーム内のデータにアクセスするために用意されている

25 コンパイル結果 class x { static int content; x(int); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/object."<init>":()v 4: iload_1 5: putstatic #2 8: return public int get_content(); Code: 0: getstatic #2 3: ireturn public void addxx(x); Code: 0: aload_1 1: invokevirtual #3 // Method get_content:()i 4: istore_2 5: getstatic #2 // Field content:i 8: iload_2 9: iadd 10: putstatic #2 // Field content:i 13: return }

26 Local Variable 3 5 Invoke 前メソッド A のフレーム 3 Invoke 完了後のメソッド A のフレーム Invoke された時の A と B のフレーム

27 ふつうは JVM Stack をきれいに使う 3 3 } 5 Invoke された B のフレーム

28 Heap vs Stack Appel, A. Shao, Z.: An Empirical and Analytic Study of Stack vs. Heap Cost for Languages with Closures, J. Functional Programming 6(1), 47 94, 特殊な構造を必要とし スタックからヒープへ移動することが必要となる場合が存在する場合は スタックを廃止してヒープ一本でメモリ管理を行う場合がよい ( 本当か?)

29 ターゲット言語の重要な要素 オブジェクト指向言語 オブジェクト Method invocation フレームは普通にスタックに積むのだが Java VM ではそこまでは強制されていない スクリプト言語 動的型付け 文字列の操作が