今のJVMに欠けている物
原文: チャールズ＝オリバー＝ナター 今日ツイッターで、「JVM及びJDKが、あらゆるプログラミングにおいて真にイケてるプラットフォームになる為には未だ幾つかの欠陥が有る」と呟きました。沢山の人から「もっと詳しく」とせっつかれたので、ここに短く書き起こしておきます。勿論、これで全部という訳ではないのでしょうが、今日思いついたのはこれだけです。 ゼロから起動する際のパフォーマンス現存するJVMの起動はかなり速いですが、Java 7でのHotSpot（訳注：Sun及びオラクルのJVM）にはこれをより良くする為の改良が盛り込まれています。普通、こういった改良は、バイトコードを予め検証したり（或いは検証の為のヒントを与えたり）、クラスデータを幾つかのプロセスで共有したり、在り来たりではありますがプログラムのロード時間やリンク時間を短縮する工夫を凝らす事で成し遂げられます。ところが、多くのアプリケー
Matzにっき(2010-05-10)
_ [Ruby] GC mark改善案 おひさしぶり。 GC sweep時間はわりと短縮できそうなので(authorNariくんがLazySweepパッチを書いてくれたし)、 このところGC mark時間を短縮するアイディアはないか、考えている。 今のRubyに入れたいので、制約として、 保守的 mark&sweep write barrierを導入しない というものがある。 しばらく前にTwitterで、「いくつかのオブジェクトをまとめて、その単位でマークする」というアイディアを披露してみたが、すぐに三浦さんから「トラバースのコストが減らないから効果ないんじゃない」との指摘が。ちょっと考えてみたら、確かにその通り。かっくり。 まあ、50年間、いろんな人が考えてきたGCで、画期的なアイディアを思いつくのは難しいよね。 まあ、そういう「誰も知らない系」ではなくて、mark時間短縮に効果のあり
YARV(Yet Another RubyVM)アーキテクチャ
これは？ Compiler (compile.h, compile.c) VM Generator (rb/insns2vm.rb, insns.def)命令記述 VM (Virtual Machine, vm.h, vm.c)レジスタ スタックフレームメソッドローカルフレーム ブロックローカルフレーム クラスフレーム フレームデザインについての補足 メソッド呼び出しについて 例外例外テーブル rescue ensure break, return（ブロック中）、retry 定数の検索定数検索パス 最適化手法threaded code Peephole optimization inline method cache inline constant cache ブロックと Proc オブジェクトの分離 特化命令 命令融合 オペランド融合 stack caching JIT Compile
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
