From: SASADA Koichi <ko1@...>
Date: 2010-08-18T03:22:08+09:00
Subject: [ruby-dev:42053] Re: [Bug #3136] reuse of singleton method definition causes SEGV

　ささだです．

(2010/08/12 18:31), _ wanabe wrote:
> 解決方法 1. はきつそうだったので、2. の方向で試してみました。
> これで本チケットおよび 2502 は発症しなくなりました。
> 複製することによる副作用に思い当たらないので、
> 反対がなければコミットしてしまおうと思っています。

　とくに，他に問題が無いようでしたらお願いします．


----
以下，VM の中身に関する余談．

　ちなみに，この辺の設計を全部やり直そうと考えています．

　この問題（もしくは，別の問題）の根本的な原因は，iseq が klass とかを
持ってる（iseq を用いてメソッドを定義したとき，そのクラスを iseq がくっ
つける）という設計がまずい，ということは数年前から気にしていたんですが，
面倒なので放置していました．

　この問題が面倒なのは，静的な（lexical な）情報と，動的な情報（定義した
クラス，みたいな）を，なんかぐちゃぐちゃにしている Ruby の挙動に問題があ
るんですが，さて，その辺が整理できていない，という話です．

　Ruby 1.8 までは，この辺の静的な情報も動的な情報も，すべて実行時にス
タックに積むことで問題なく実現していました．RHG でいう，「7本のスタッ
ク」に，実行時に積んでいたわけです．

　Ruby 1.9 というか YARV の目標は，高速化ですから，なるべく実行時に何か
積むのは嫌だなぁ，と思って全体を設計しています．なので，iseq->klass のよ
うな実装になっているわけです．

　で，いろいろ考えたんですが，実行時に，毎回制御フレームごとに積んでいる
iseq をやめて，その辺の諸々の情報（iseq とか，klass とか，cref とか．名
前はまだ無い）を含んだ何かを積むことにしようかと．その何かは，メソッド定
義なんかの時に，作ることになります．

　ちょっと面倒なのは，そのメソッド定義で利用される iseq が参照しているブ
ロックなども，その何かを正しく参照できなければならない，ということでし
た．ここが，この実装にするときの面倒な点で，腰が重かった理由でもあります．

　Ruby の挙動がもう少しおとなしければ，制御フレームをうまくたどって，み
たいな実装も考えられると思うのですが，なんとか eval とか，define_method
とかやっちゃうやんちゃな人なので，それもうまくいきません（何度か考えてみ
たんだけど）．

　で，結局メソッド定義時にきちんとその辺の情報を再帰的にたどって整備する
のが早道かなぁ，という結論になりました．ので，そう実装しようと思っています．

# クラス定義時にはどうなるんだろう．
# defineclass 命令とかで情報の伝搬が走るのかな．

　1.9.3 では，この辺の問題が綺麗に整理されているといいなぁ．

-- 
// SASADA Koichi at atdot dot net