アカウント名:
パスワード:
従来 VMware 上などで実行するOS/プログラムの性能が、直接インストールしたものに比べてかなり性能低下するのが、これによってほとんど直接実行しているのと変わらなくなるでしょう。
こういった命令が一般化すれば、恩恵を受けるのは複数OSを使う必要がある開発者ばかりでなく、仮想化OSをサンドボックスとしてウィルス保護に使うなど、応用も広がると思います。
まあ、これらはメインフレームが辿った道なんで、順当な路線ということでしょう。
Java VMの命令セットと物理CPUの命令セットの間に特に関係がある訳じゃないんで、残念ながら幸せになったりはしないと思います。
そうでもないですよ。 JRockit VM の BEA Systems は Bare Metal [beasys.co.jp] なんてものを考えています。
また、今後のユーティリティコンピューティングの実現を目指した取り組みの1つとして、ハードウェアおよびアプリケーションの仮想化テクノロジーを活用することで、OSを介在することなくIntelのVT（Virtualization Technology）対応プロセッサ上で直接JRockitを実行可能にするプロジェクト「Bare Metal」も紹介された。
既に、ITRONなどのRealTimeOS上のJavaVMなどはごろごろしています。オーバヘッドの少なさだけならこっちの方が有利そうです。ただし、これらの実装で性能が稼げそうなのは、大量のスレッドを動かすような使い方をしたときだけだと思います。
それでも汎用のＯＳと一緒に、この高性能JavaVMを同時に動かせるのは悪くはないですね。
いや、RealTime OS の上に載っているのが Java VM だけで他のネイティブコードが走っていないなら、CPU をスーパーバイザモードで突っ走らせるという荒業があります。
アプリケーションが全部 Pure Java コードなら、プロセス外のメモリへの参照も特権命令の勝手な実行も起きません。それらは全て Java VM が監視できます。すると CPU のユーザモードを使う必要がなくてスーパバイザモードのまま走らせても安全なんです。
これは I/O の速度に効いてきます。I/O 処理中に CPU のモードを切り替える必要がありませんから。なのでそんな環境はネットワーク通信だけ妙に早かったりします。
実用場面では Pure Java では実用性に欠けるので広まりませんでしたが、ネタとしては面白いと今でも思っています。
前の記事の参照先を見ればよかったです。
BEA がやるとネタですまないかも、と思ったのだけれど、CPU のモードを変えないことが狙いだとすると VMM があったら元の木阿弥なんですよね。BEA がやろうとしていることはちょっと違うんだろうなあ...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
具体的に何がうれしくなるの？ (スコア:3, 興味深い)
VMM のための新しい命令が追加されるの？それってたとえば SIMD 命令群が用意されたから特定の処理が早くなりますよ、うれしいね、ってのと似てる？わかんないんでとりあえず Intel の文書 [intel.com]に当たってみます。
屍体メモ [windy.cx]
Re:具体的に何がうれしくなるの？ (スコア:5, 参考になる)
従来 VMware 上などで実行するOS/プログラムの性能が、直接インストールしたものに比べてかなり性能低下するのが、これによってほとんど直接実行しているのと変わらなくなるでしょう。
こういった命令が一般化すれば、恩恵を受けるのは複数OSを使う必要がある開発者ばかりでなく、仮想化OSをサンドボックスとしてウィルス保護に使うなど、応用も広がると思います。
まあ、これらはメインフレームが辿った道なんで、順当な路線ということでしょう。
の
Re:具体的に何がうれしくなるの？ (スコア:0)
ド素人なんで的外れかもしれませんが、もしかしてJavaのVMも幸せになったりするんでしょうか？
Re:具体的に何がうれしくなるの？ (スコア:2, 参考になる)
Java VMの命令セットと物理CPUの命令セットの間に特に関係がある訳じゃないんで、残念ながら幸せになったりはしないと思います。
今回の話っていうのはいわば物理CPUの命令を直接使うOSたちをだましてしまおうという話なので、物理CPUをそのまま使う訳ではないJava VMには直接の関係はないといえるでしょう。
# 投稿ついでに余計なものもくっつけておきますね。
ずいぶん前からVMwareを使ってますけど、I/Oの絡まない処理は
Re:具体的に何がうれしくなるの？ (スコア:4, 参考になる)
そうでもないですよ。
JRockit VM の BEA Systems は Bare Metal [beasys.co.jp] なんてものを考えています。
コンタミは発見の母
Re:具体的に何がうれしくなるの？ (スコア:1)
言われてみれば直接高速化を図らずともこういった手段はありますね。
ちょっと探してみたら上記Bare Metalに関しては日経IT Proの方にも記事 [nikkeibp.co.jp]がありました。
確かに実現すればJava VMの下に汎用OSが寝ている分のオーバーヘッドは回避できそうです。ハ
Re:具体的に何がうれしくなるの？ (スコア:3, 興味深い)
既に、ITRONなどのRealTimeOS上のJavaVMなどはごろごろしています。オーバヘッドの少なさだけならこっちの方が有利そうです。ただし、これらの実装で性能が稼げそうなのは、大量のスレッドを動かすような使い方をしたときだけだと思います。
それでも汎用のＯＳと一緒に、この高性能JavaVMを同時に動かせるのは悪くはないですね。
Re:具体的に何がうれしくなるの？ (スコア:2, 興味深い)
いや、RealTime OS の上に載っているのが Java VM だけで他のネイティブコードが走っていないなら、CPU をスーパーバイザモードで突っ走らせるという荒業があります。
アプリケーションが全部 Pure Java コードなら、プロセス外のメモリへの参照も特権命令の勝手な実行も起きません。それらは全て Java VM が監視できます。すると CPU のユーザモードを使う必要がなくてスーパバイザモードのまま走らせても安全なんです。
これは I/O の速度に効いてきます。I/O 処理中に CPU のモードを切り替える必要がありませんから。なのでそんな環境はネットワーク通信だけ妙に早かったりします。
実用場面では Pure Java では実用性に欠けるので広まりませんでしたが、ネタとしては面白いと今でも思っています。
Re:具体的に何がうれしくなるの？ (スコア:1)
前の記事の参照先を見ればよかったです。
BEA がやるとネタですまないかも、と思ったのだけれど、CPU のモードを変えないことが狙いだとすると VMM があったら元の木阿弥なんですよね。BEA がやろうとしていることはちょっと違うんだろうなあ...