MAEDA Atusi <maeda-yarv atusi.org> wrote :
    [ [yarv-dev:263] Re: VM state version problem ]
    at 21 Oct 2004 13:58:06 +0900

　ささだです。

> 問題はオーバーフローでなく、一周して戻ってきちゃうことですね。
> 大小関係じゃなくて等しいかどうかでヒットを判定するので。

　はい。

> インクリメントするのはメソッドとかクラスが再定義された時ですよね。
> 少々遅くても良いのでは。

　そうですね。浅はかでした。


> アトミックにやらなければいけないのは、
> ・メソッド等の再定義
> ・カウンタのインクリメント
> ですよね。
> 
> writerは互いに排他制御するとして、readerに対してはwriterが、
> 1. 旧バージョンのメソッドを仮に、その場で無限ループするようなコードと
>    か、ブロックするようなコードに書き換える。
> 2. カウンタをインクリメントする。
> 3. メソッドを本物に書き換える。
> 4. 無限ループあるいはブロックしているreaderを本物のコードへ誘導。
> という順序で処理すれば良さそうな気がします。

　頭の中がまとまっていないので、もう一度出直してきます。本当に
そのような実装でいいのか、自信がありません。


>> 　昔から、リファレンスカウンタの値がオーバーフローしたらどう
>> するんだろう、と疑問に思ってるんですが、何か対策を立てるもの
>> なんでしょうか。
> 
> 素朴にはオーバーフローしないサイズをとります。アドレス空間が32ビットな
> ら、28ビットとれば十分(すべてのワードから指されてもOK)。

　なるほど。大変わかりやすいです。


　分散環境上での GC とか、それではすまなそうなのですが、そう
いうのは 64bit とか取ればいい、とか言ってしまえばいいんでしょ
うか。

　32bit マシンのすべての word にオブジェクトができて 28bit。
　64bit カウンタを消費するためのマシン数は 2**36 = 68,719,476,736台。

　まぁ、問題ないのですね。なるほど。

　32bit カウンタだと、2**16 = 65536台。

　まぁ、ありえないか。

-- 
// SASADA Koichi at atdot dot net
//


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