K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>>>これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。
>>>crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと
>>>GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。
>>
>>私はよく分かっていないのですが、このcrowbarのアプローチは
>>メジャーなのですか？
>
>たぶん、メジャーでも、望ましいものでもないと思います。
>Rubyだと、GCがCスタックをスキャンするから何もしなくてよく、
>Pythonだと、参照カウンタを上げたり下げたりを手でやらなければいけなかったと
>思いますが(過去形?)、たとえばJavaのJNIでは、別にCスタックをスキャンする
>わけでもないのに、確保したオブジェクトについては特に何もする必要はありません。
>
>JavaHouseにある首藤さんの記事によれば、
>
>http://java-house.jp/ml/archive/j-h-b/013314.html
>| JNI: native method のフレームごとに local references (の表) を用意、
>|      local references から辿れるオブジェクトは回収しない。
>
>とのことです。
>crowbarでも、CRB_dev.hにあるオブジェクト確保系の関数群において、自動的に
>参照をスタックに積んでしまうことは可能です。ネイティブ関数実行後スタックを
>戻す処理も、処理系側で苦もなくできます。
>なぜ今そうなっていないかというと… うーん、何故なんでしょう? (^^;
>たとえば、オブジェクトを確保して、すぐに既存の配列の要素にセットする、
>という場合、特にスタックに積む必要はないのでその辺の無駄を嫌ったような
>気がしますが、現状の仕様は、「いつGCが起きる可能性があるか」という点について
>crowbarの内部実装をネイティブ関数の作者に晒していることになりますから、
>大変よろしくないですね。次バージョンでは修正します。
>
>ネイティブ関数側で、大量のオブジェクトの確保/破棄を繰り返すような処理が
>あるとすると、スタックが大量に無駄になりますが、そんなことわざわざ
>ネイティブ関数で書かないですよねえ… あるいはその場合でも、
>ネイティブ関数用を呼び出したときのCRB_LocalEnvironmentに
>local referenceの表を持ち、スタックではなくそちらに参照を入れるようにして
>おけば、ネイティブ関数のプログラマに手で解放させることも不可能ではないですし。
>
>>>ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。
>>>そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は
>>>ありません。ただし、外部crowbarスクリプト中の関数であれば、
>>>CRB_compile()とCRB_call_function()を使えば実行可能です。
>>
>>外部crowbarスクリプト中の関数を呼べるということは、
>>データを引数でC側からcrowbarの関数側にプッシュしてあげて、
>>crowbarスクリプトのglobal変数に保存しておけば、
>>データの共有はできると思います。
>
>誤解させる書き方をしてしまったかもしれませんが、CRB_compile()と
>CRB_call_function()を使う方法なら、インタプリタを共有できますから、
>グローバル変数によるデータ共有が可能です(まあ、引数で受け渡しするほうが
>よいのはよいでしょうけど)。
>
>>私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして
>>「プログラミング言語を作る」もぜひ出版して欲しいです。
>>早くていつ頃になりそうですか？
>
>いやあ、それはさっぱりわかりません。
>まだ企画が動き出したわけですらないですし。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！