------------------------------------------------------------------
第 353 回 PTT のお知らせ
--- Programming Tools and Techniques ---
------------------------------------------------------------------
■日時: 2009年3月26日(木) 18時30分から
■話者：川口 直也 (東京農工大学 工学府情報工学専攻 博士前期課程 並木研究室)
■題名：Javaによるx86ユーザーモードエミュレータの実装とアプレット化の試み
■概要：
既存のx86/Linuxアプリケーションの異種環境間における可搬的実
行を可能とするためのユーザーモードエミュレータをJava言語で実
装した．ユーザーモードエミュレータはCPUの機械語命令のうち，
ユーザモードの命令のみをエミュレーションし，システムコールは
エミュレータが動作している環境のネイティブなシステムコールラ
イブラリを利用する．これにより，エミュレータの動作環境のファ
イルシステムやネットワークI/Oを仮想化することなく，アプリケ
ーションから透過的に利用可能とするものである．本研究では，ユ
ーザーモードエミュレータをJava言語で実装し，エミュレータのバ
イナリ自身にも可搬性を持たせるとともに，Linux用GUIプログラム
をJavaアプレットとしてWebブラウザ上で動作させることを可能と
した．また，マルチスレッドや，ld.soをエミュレーションするこ
とによる共有ライブラリのロードにも対応している．発表ではエミ
ュレータの機能と実装を紹介し，簡単なGUIプログラムをブラウザ
上で動作させデモを行う．
■場所: 東京農工大学工学部7号棟 3階 3K室
JR中央線東小金井駅南口から，西へ向かって徒歩8分程度です．農
工大の東門に建物の配置図があります．
http://www.cs.tuat.ac.jp/2/contact.html をご参考ください．な
お，現在中央線高架化の工事に伴い，上り線と下り線のホームが北
口・南口に分割されています．上り線ホーム北口から農工大に行く
場合は，改札を出て右手の地下道をくぐり農工大のある南口に向っ
てください．
------------------------------------------------------------------
第 353 回 PTT report
・レジスタ/メモリについて
Q．メモリを可変長にする理由は？
A.mmapした場合にサイズが変わるから．固定長＊複数ではx86以外でページサイ
ズが違う場合に問題．
Q.メモリを確保するタイミングは
A.プログラムがアクセスしたとき．
Q.ポインタと実際の配列との対応は？ポインタアクセスしたときのアクセスコス
トが大きい？
A.線形に探索，コストはとても大きい．ただし，現在は他の部分にボトルネック
があり，あまり大きな問題にはなっていない．
・FPU
Q.gccでlong doubleを利用したら（80bitフルに使えるのでは）？
A.知らなかった
・命令エミュレーションの流れ
Q.これは一命令ごとのエミュレーション？それ毎に命令の対応をCSVから読み込む？
A.起動時に一括して読み込む
・命令エミュレーション
Q.JNI使うのは何故？ポータビリティを考えるとネイティブのコードを使うのは問題では？
A.自分で全部書くのはコストが大きいから
Q.パイプラインのエミュレーションは行いたい？メリットある？
A.わかりません．
C.速さには寄与しないが挙動を知るのにはいいかも．
・POSIXシステムコール
Q.Posixシステムコールを下のOSに丸投げ？（OS毎の仕様の違いにより）そのま
までは動かないのでは？
A.Cygwinに投げている
C.QEMUのユーザモードエミュレーションはこのあたりの問題で動かないと言われ
るのでは．QEMUの問題点を改善しているわけではない
Q.PosixシステムコールのJAVA上でのエミュレーションは難しい？
A.先行研究にあり．ただし，pthreadはサポートしていない．
・実装
Q.何がコードサイズで大きい部分を占める？
A.命令エミュレーションが大きい．1000命令以上をエミュレート．FPU以外の命
令はほとんど．
C.同じような命令はうまく共通化できないか
Q.システムコールが環境によって動かないのは研究の目的との合致していない．
問題として認識？
A.汎用性という意味では問題．デスクトップAppをブラウザ上で動かすという意
味ではWindows上で動作するのは大きな成果．
・評価
Q.評価はVMWare上で計測したサイクル数？
A.そう
Q.ネイティブのサイクル数は計測オーバヘッド入ってない？
命令数（add）に対してサイクル数が大きすぎる．どうやって計測？
A.rdtsc命令で計測
C.add命令一つに1000サイクルはかかりすぎ．addを0個で計測してみると良いかも
Q.実際に評価は何分くらいかかるのか
A.fib20で100数十秒
・評価まとめ
C.リフレクションを使ってる時点で遅いのは当然
C.（オーバヘッド解析）評価はグラフにしよう
5%は大きく，その部分もどうにかすべき
Q.CPUのキャッシュはエミュレート？
A.やっていない
Q.mmapのところで割り当てたアドレスの大小関係を利用したい場合等問題が出る？
A.Appからは元のアドレスで見えるので問題ない
Q./dev/zeroを読み書きするとシグナル発生．そこまでできる？
A.下で発生したシグナルをJAVA側に通知
Q.forkはどう実装
A.現在してない．実装する場合は一つのプロセスとして実際にforkする
Q.目標性能（2〜8倍）をどのように達成する？
A.デコーダを変える
Q.どれくらいまで高速化できる
A.デコーダを変えるなどで抜本的な解決をして，数千倍程度までと思われる
Q.あらかじめ実行ファイルの中身をすべてデコードして命令とメソッドの対応関
係をキャッシュしておけば速い？
A.間接分岐命令で問題．どこに飛ぶかわからないので
Q.評価は何故VMWare上で評価？
A.Linuxを利用したかった
C.評価には適さない
Q.mipsのQEMUとは何が違う？速度は同等程度まで行く？
A.実装をサボった部分で差が大きい．
C.一つ一つのシステムコールや命令の性能をまず測り，そこからボトルネックを
改善していった方がいいかも
C.メモリのプロテクト関連はエミュレータで何をやっているのか，面白いことが多そう
A.現在は下に落とすだけ
C.高速化するとしたらMMUがやってるページングのようなことをエミュレータでやるべき
Q.ダイナミックリンクはもっとサポートしたら．
大変だがlibcをJavaでエミュレートしてみたら？
x86命令をエミュレートする部分が少なくなるので高速化できる
A.できるかも
Q.関数コールになってるところはエミュレートできる？
A.できる
Q.リッチなデバッガなど，エミュレート以外の用途に使える？
A.SQLiteでデバッグ機能を付加．（それをデバッグに使えるかも？）
Q.共有ライブラリの依存関係が複雑だと動かすのが難しいのは何故？
A.命令エミュレーションのバグにより，エミュレーション失敗する確率が高くなるから
C.リフレクションではなく，
x86コードをバイトコード自体に変換すると速くできそうだが……