ささださん、皆様、首藤です。

> > 再定義されていない (キャッシュにヒットしている) 状態でも
> > 条件分岐があるというのはヌルいですが、
> > Ruby だし、そのくらいでいいのかな、と思ってました。

Ruby だし、というよりも、
どうせ普段から条件分岐がいろいろあるインタプリタだから、
でした。

> > バイトコードインタプリタなら、バイトコード命令を置き換えれば済むから、
> > それほど難しくないように思います。
>
> 　そうですね．ただ面倒くさいだけの作業になりそうです．

再定義をフックして、影響のある箇所を見つけて、
そこのバイトコード命令を書き換える、ということになるかと。

似たような機構を shuJIT に実装しようと考えた際は、
表の管理が面倒そうだな、と思いました。

> >> ・AOT compiler も同様の理由でよろしくない
> >
> > AOT コンパイラだからといってコード書き換えはできます。
>
> 　再定義された場合とされていない場合を両方用意して，再定義が
> 起こったらそちらに差し替え，とかでしょうか．

(AOT に限った話ではないですが、)
最初は、再定義が起きないことを前堤とした最良のコードにしておいて、
再定義が起きてしまったら、メソッド探索処理に飛ぶように
コードを書き換える。と。

> 　マシンスタックフレームを解析しないと出来ないぽいですね．

どうでしょう？

> さすがにそこまではやれなさそう．shujit ではされたんですか？

さすがに、メソッド探索が不要であることが
静的に自明 (private, final メソッド) な場合には探索しないようにしましたが、
探索が必要になるかもしれない呼び出しを nonvirtual な呼び出しに置き換える
という最適化 (IBM TRL 用語で devirtualization) まではしませんでした。

インラインメソッドキャッシュは、
interface 呼び出し (JVM の invokeinterface 命令) にだけ、
適用しました。

Kazuyuki Shudo/首藤一幸   私をたばねないで あらせいとうの花のように
  shudo computer.org   http://www.shudo.net/

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml