LlGetFreeMemory/ja
From Second Life Wiki
仕様
この関数のふるまいは、スクリプトが使っている仮想マシン (Virtual Machine, VM) に依存します。Mono は新しい VM、LSO はその前の古い VM です。Mono と LSO の大きな違いは、Mono はスクリプトの実行速度が速く、また使えるメモリが 4 倍ある事です。
Mono
Mono の場合の戻り値は、ガベージ コレクションに先立ってスクリプトが使用可能な空きメモリの量です。これは即ち、ガベージ コレクション間近のメモリは、スクリプトに割り当てられた 64KB を丸々利用できる状態にはない事を意味します。付け加えると、Mono は LSO VM 程にはメモリの制約が厳しくなく[1] (LSO は 16KB 以上のメモリは利用不可能でした)、結果的により多くの空きメモリを利用できます。
LSO
LSO の場合の戻り値は、ヒープ領域としてまだ使われていない、スタック領域が使用できる空きメモリの量です。
LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。
string、list、key はヒープに格納されます。ヒープ (string、list、key) のポインタ、integer、float、vector、rotation はみなスクリプトの実行時、一時的にスタックに格納されます。
スクリプトが実行される際、処理の複雑さに応じてスタックのサイズは増減します。ヒープのサイズも、増加は同様ですが、スタックとは異なり減少することがありません。スタックとヒープの間に使用可能な空きメモリが無くなると、両者が衝突して Stack-Heap Collision エラーが発生し、スクリプトは異常終了します。
ヒープにはフラグメントが生じることがあり、そこには (個々のサイズが小さいゆえ) 使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが[2]、フラグメントを抑制するコツはあります。
例
以下は llGetFreeMemory の使用例です:
integer free_memory = llGetFreeMemory(); llOwnerSay("割り当て可能な空きメモリが " + (string)free_memory + " KB あります。");
ディープノート
LSO VM ノート
この関数は空きメモリの量を返しません。この関数名は、理解の妨げになっています。LSL VM が Mono へ移行した暁には、この関数は再定義されるか、もっと有用な別の関数に置き換えられるかもしれないと言われています。
並列タスク/スレッド/プロセスで使われる典型的な Unix モデルに沿って llGetFreeMemory を簡潔に説明できます。すなわち、スクリプトのタスクが常に 16384 バイト (16 KB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。llGetFreeMemory は "ヒープが今まで一番下まで下がった地点" から "スタックの最上点" を差し引いた値を返します。
llGetFreeMemory は開放されたメモリは考慮しません。まだ使われた事のないメモリの総量を返します。
Footnotes
- ^ http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html
- ^ LSO VM の設計上、デフラグ関数は実現不能です。
