Shiro Kawai <shiro lava.net> wrote :
    [ [yarv-dev:473] Re: Multi-VM instance ]
    at Sun, 24 Apr 2005 22:27:29 -1000 (HST)

　ささだです．
　相変わらず迅速で的を得た返信，感謝します．


> クラス定義などのメタ言語要素がランタイムに存在していじれちゃう言語の
> 場合、ここの設計は結構微妙だと思います。
> 
> ひとつのVM (VM-A)でStringクラスを再定義したとして、そのVM内のString
> インスタンス(s)が別のVM (VM-B)に渡された場合、s.classは再定義
> されたStringクラスのインスタンスなのか、オリジナルのStringのインスタンス
> なのか。再定義されたStringクラスだとすると、VM-B上で String === s は
> falseになるのか、等。

　VM-B::String === s.calsss だと思いました．

　で，(VM-A::)String === s は，もし VM-A::String が再定義さ
れていれば false．

　VM-A::String も VM-B::String も再定義されていなければ true ...
にしたいと思ったんですが，なんか実装が思いつかないな．


>> 　のプリミティブって何を使ってますか？　gcc 拡張の tls？
>> それとも，pthread_getspecific()？
>> 　私は tls を使おうと思ってたんですが，その辺のオーバヘッド
>> （x86 なら，セグメント指定が入るため）が気になっています．
> 
> 今はpthread_getspecific()です。とりあえずそれが一番ポータブルだと
> 思うんで。いずれ__GNUC__ の場合にtlsも試してみようとは思ってます。
> pthread_getspecificより重いってことは多分無いですよね?
> 
> ちなみにGaucheでは、pthread_getspecificのオーバヘッドは、
> ほとんどの場合0.1%以下、悪いケースでたかだか2%くらいです。それよりは
> GCとかクロージャをオプティマイズする方がずっと効果が高いので、
> たぶん当分はpthread_getspecificのままにしておくと思います。

　なるほど．

　気にしているのは，旧 C API 対応のために，毎回 tls から VM
またはスレッドインスタンスを取ってこなければならないという
点でした．

（救うのは旧 C API を利用している各種拡張ライブラリ）


　その程度のコストであれば，作ってから考えるということで十分
対応できそうですね．

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

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