セッション11 : メタレベルアーキテクチャとリフレクション
08:58 <#0:Ichiji> おはようございます．
08:59 <#0:Ichiji> ★OpenJIT: An Open-Ended Reflective JIT Compile Framework for Java★
09:03 <#0:kawa> おはようございます。
09:03 <#0:kawa> よかった。。。
09:04 <#0:kawa> SPA Y2Kだ
09:05 <#0:Ichiji> ??? > SPA Y2K
09:05 <#0:kawa> 画面の下に書いてあります
09:05 <#0:Ichiji> おおお．．．．
09:09 <#0:kawa> JITをコンパイルするJITをコンパイルする、、、
09:10 <#0:sohda> http://www.OpenJIT.org/ です
09:10 <#0:maruyama> See http://www.openjit.org/
09:13 <#0:kawa> JIT を deploy する仕組みもあるのかなぁ
09:15 <#0:mich> IBM の JIT とは比べてみました？＞パフォーマンス
09:16 <#0:sohda> WWW.OpenJIT.org に載せてあります＞パフォーマンス
09:18 <#0:kawa> T図式って書けるのかな
09:21 <#0:kato> 勝ってるんですか？＞パフォーマンス
09:22 <#0:maruyama> IBMのものや、HotSpotのようなモダンなVMにはかなり負けてます。
09:22 <#0:maruyama> が、ClassicVM + sunwjitとはいい勝負。
09:25 <#0:akr> plum が落ちて log を 1行とり損ねた...
09:26 <#0:kato> JITを系統的に作ることのメリットをうまくアピールできるといいですね．スライドの最初の方では，性能面でも勝てそうな話でしたが．
09:26 <#0:wakita> われわれはGCを一般の言語で比較しようとしています。
09:26 <#0:wakita> SPEC GC for Java の基盤として Open JIT は関心をもっています。
09:27 <#0:wakita> このためには、やはりパフォーマンスが欲しいのですが。。。
09:27 <#0:kawa> JAVAで書いてあっても、JIT自身もコンパイルしているんですよね
09:27 <#0:maruyama> はい。
09:27 <#0:kawa> JITをコンパイルする時間はベンチマークに入ってるんですか？
09:28 <#0:maruyama> 入っています。selfコンパイルの時間も入っています。
09:28 <#0:kato> 性能比較の図が見にくいわ
09:30 <#0:kawa> JITは1回コンパイルするだけでよいような。。（適応の場合は別ですが、、）
09:30 <#0:kawa> 縦軸が違うんですね
09:30 <#0:kawa> よく見ると横軸も違う
09:30 <#0:kato> やっぱり図が見にくいわ．字も小さいし．
09:31 <#0:wakita> それぞれのピークがどの部分のコンパイルに消費されているのか見たいなぁ。
09:31 <#0:sohda> 論文の19〜２０ページを見てください＜グラフ
09:31 <#0:kawa> せめてどのグラフが何を意味しているかを知りたい
09:31 <#0:kato> まさかわざと見にくくしてないわよね
09:32 <#0:maruyama> これまで説明されたグラフは、横軸が時間で縦軸が、ヒープ使用量です。
09:33 <#0:maruyama> 最初の４つのグラフは、単純なプログラムの代表としてHelloの場合について
09:34 <#0:maruyama> sunwjitやインタプリタの場合と、OpenJITの場合の振る舞いをそれぞれ表しています。
09:34 <#0:kato> この線の種類は見分けられないわ
09:34 <#0:maruyama> そのあとの、真っ黒なやつは、SPECjvm98程度の大きさのプログラムになるとsunwjit
09:35 <#0:maruyama> でもOpenJITでも、ヒープの使用状況はそう変わらないという主旨のグラフです。
09:41 <#0:MATSUBARA> 字が小さくて良く見えないですね。
09:42 <#0:wakita> 若かりしころに、Times-Roman 12pointを使ったことがあります。
09:42 <#0:wakita> 松岡さんにしかられました。「フォントが間違っている」
09:43 <#0:wakita> 以来、> 18 pointの人になってしまいました。
09:43 <#0:Takuo> 拡張の合成に適したメタレベルの構成
09:44 <#0:Takuo> 確かに字が小さいですね．すみません．しかも地味だ．
09:45 <#0:kawa> メタレベルアーキテクチャのメタな話？
09:46 <#0:MATSUBARA> フォントもゴシックとhelveticaにした方が見易いかもしれません。
09:46 <#0:Takuo> メタレベルをどうやって使いやすいようにデザインするか，という話です．
09:47 <#0:Takuo> こうやって共著者がどんどん答えるのはよくないですね．
09:47 <#0:Takuo> あとでつっこんでやってください．
09:47 <#0:kawa> うーん。右肩の数字がレベル？
09:50 <#0:wakita> 操作的意味論を属性文法で書き直しているような。。。
09:55 <#0:wakita> 規則の過剰が、機能をoverrideできない？？（例を使って説明して欲しい）
09:55 <#0:kawa> メタレベルで言語を定義できるわけですね
09:55 <#0:kawa> で、モジュール間の整合性の問題があったりすると、、
09:56 <#0:kawa> この図がよく読めない
09:56 <#0:hirotsu> 開発時の意図を保証するために全てのモジュールを持つと、容易に衝突が起こったりしないのでしょうか
09:57 <#0:kawa> なんだか、インタプリタを書いているみたいですね
10:00 <#0:wakita> 代入を付加するときに、store の構造が変化しますが、そういうことは表現できるか。。。
10:01 <#0:kawa> この枠組みにはメタメタは存在しない？
10:03 <#0:hara> wissでは逆に共著者がchatで答えることは歓迎されています．>Takuo
10:05 <#0:wakita> 考えてみれば let は lambda の syntax sugar だから、単なる構文の拡張に過ぎないのではないか？
10:05 <#0:mich> 「メタレベルのデザイン」が「属性評価規則のデザイン」に集約される枠組み？
10:05 <#0:kawa> インタプリタの合成って感じかな
10:05 <#0:kawa> Java + VB とか :-)
10:06 <#0:wakita> 属性文法のうまみはどこ？
10:12 <#0:my> envではなくて storeを追加だよね > wakita
10:12 <#0:wakita> はい、その通りです。
10:14 <#0:kawa> そういういみでは、メタレベルアーキテクチャではなかったのかなあ。。。
10:15 <#0:wakita> 可愛い。
10:25 <#0:my> superという変数なんて(今は)存在しないのでは?
10:26 <#0:mich> ソースで？バイトで？
10:28 <#0:my> super.f1 か super.m1() しか許されないはず(ソースでいえば)
10:28 <#0:mich> そうです
10:30 <#0:mich> ソースでいうところのsuper no
10:30 <#0:mich> の話だったと思います
10:31 <#0:wakita> JVM上でのtype-safe な bytecode instrumentationをサポートするシステムはあるのでしょうか？