Difference between revisions of "LlGetFreeMemory/ja"

From Second Life Wiki
Jump to navigation Jump to search
m (Add {{Help/Old_Info/ja}})
(Update translation)
Line 1: Line 1:
{{Help/Old_Info/ja}}{{LSL_Function/ja
{{LSL_Function/ja
|func_id=225|func_sleep=0.0|func_energy=10.0
|func_id=225|func_sleep=0.0|func_energy=10.0
|func=llGetFreeMemory|sort=GetFreeMemory
|func=llGetFreeMemory
|return_type=integer
|return_type=integer
|func_desc
|func_desc
|return_text=スタック領域が使用できる空きメモリのバイト数
|return_text=スクリプトが使用できる空きメモリのバイト数
|func_footer
|func_footer
|spec=
|spec=
この関数のふるまいは、スクリプトが使っている仮想マシン (Virtual Machine, VM) に依存します。[[#Mono|Mono]] は新しい VM、[[#LSO|LSO]] はその前の古い VM です。Mono と LSO の大きな違いは、Mono はスクリプトの実行速度が速く、また使えるメモリが 4 倍ある事です。
===Mono===
Mono の場合の戻り値は、ガベージ コレクションに先立ってスクリプトが使用可能な空きメモリの量です。これは即ち、ガベージ コレクション間近のメモリは、スクリプトに割り当てられた 64KB を丸々利用できる状態にはない事を意味します。付け加えると、Mono は LSO VM 程にはメモリの制約が厳しくなく{{Footnote|http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html}} (LSO は 16KB 以上のメモリは利用<u>不可能</u>でした)、結果的により多くの空きメモリを利用できます。
===LSO===
LSO の場合の戻り値は、ヒープ領域としてまだ使われていない、スタック領域が使用できる空きメモリの量です。
LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。
LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。


Line 13: Line 23:
スクリプトが実行される際、処理の複雑さに応じてスタックのサイズは増減します。ヒープのサイズも、増加は同様ですが、スタックとは異なり減少することがありません。スタックとヒープの間に使用可能な空きメモリが無くなると、両者が衝突して Stack-Heap Collision エラーが発生し、スクリプトは異常終了します。
スクリプトが実行される際、処理の複雑さに応じてスタックのサイズは増減します。ヒープのサイズも、増加は同様ですが、スタックとは異なり減少することがありません。スタックとヒープの間に使用可能な空きメモリが無くなると、両者が衝突して Stack-Heap Collision エラーが発生し、スクリプトは異常終了します。


ヒープにはフラグメントが生じることがあり、そこには使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが、フラグメントを抑制するコツはあります。
ヒープにはフラグメントが生じることがあり、そこには (個々のサイズが小さいゆえ) 使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが{{Footnote|LSO VM の設計上、デフラグ関数は実現不能です。}}、フラグメントを抑制するコツはあります。
|caveats=
|caveats=
*ヒープが使用可能な空きメモリは、これより多いかもしれません。(少なくともこれ以下ではありません。)
*ヒープが使用可能な空きメモリは、これより多いかもしれません。(少なくともこれ以下ではありません。)
Line 20: Line 30:
以下は llGetFreeMemory の使用例です:
以下は llGetFreeMemory の使用例です:
<lsl>
<lsl>
integer Ki = 1024; // 1024 == (1 << 10);
integer free_memory = llGetFreeMemory();
float maxPerScript = 16 * Ki;
llOwnerSay("割り当て可能な空きメモリが " + (string)free_memory + " KB あります。");
llOwnerSay((string) ((maxPerScript - llGetFreeMemory())/Ki) + " KB のメモリがスクリプトのリセット後に一回以上使われました。");
llOwnerSay((string) ((maxPerScript - llGetFreeMemory())/Ki) + " KB のメモリがスクリプトのリセット後に一回以上使われました。");
</lsl>
スクリプトをリセットしてヒープが減少した後、それが次第に増大する様子が以下のように表示されます:
<pre>
0.508789 KB のメモリがスクリプトのリセット後に一回以上使われました。
0.524414 KB のメモリがスクリプトのリセット後に一回以上使われました。
</pre>
ヒープ (の変数) を一気に縮小しても、llGetFreeMemory の戻り値は増えません:
<lsl>
default
{
    state_entry()
    {
        llSay(0,"llGetFreeMemory の戻り値: "+(string)llGetFreeMemory()+"byte(s)");
        //llGetFreeMemory が返すバイト値を出力
        if(TRUE)
        {
            list TEST1;
            TEST1=[1,5334,"Blah, blah, blah",<345,3.78,34>,<0,0,0,1>,"TEST"];
            TEST1=TEST1+TEST1+llGetFreeMemory();
            integer i;
            for(i=0;i<llGetListLength(TEST1);i++)
            {
                llSay(0,"リストの "+(string)i+" 番目の要素: "+llList2String(TEST1,i));
            }
            TEST1 = [];
        }
        llSay(0,"list 変数は削除されました。");
        llSay(0,"現在の llGetFreeMemory の戻り値: "+(string)llGetFreeMemory());
    }
} // http://wiki.secondlife.com/wiki/User:TxMasterG_Ping/llGetFreeMemory
</lsl>
</lsl>
|helpers
|helpers
Line 60: Line 38:
|also_tests
|also_tests
|also_articles
|also_articles
|notes=この関数は空きメモリの量を返しません。この関数名は、理解の妨げになっています。LSL VM が [[Mono/ja]] へ移行した暁には、この関数は再定義されるか、もっと有用な別の関数に置き換えられるかもしれないと言われています。
|notes=参考: {{LSLG/ja|LSL Errors}} の "Script run-time error"、"Stack-Heap Collision" の項
<br/>
|lso=この関数は空きメモリの量を返しません。この関数名は、理解の妨げになっています。LSL VM が {{LSLG/ja|Mono}} へ移行した暁には、この関数は再定義されるか、もっと有用な別の関数に置き換えられるかもしれないと言われています。
<br/>
 
並列タスク/スレッド/プロセスで使われる典型的な Unix モデルに沿って llGetFreeMemory を簡潔に説明できます。すなわち、スクリプトのタスクが常に 16384 バイト (16 KB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。llGetFreeMemory は "ヒープが今まで一番下まで下がった地点" から "スタックの最上点" を差し引いた値を返します。<br/>
並列タスク/スレッド/プロセスで使われる典型的な Unix モデルに沿って llGetFreeMemory を簡潔に説明できます。すなわち、スクリプトのタスクが常に 16384 バイト (16 KB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。llGetFreeMemory は "ヒープが今まで一番下まで下がった地点" から "スタックの最上点" を差し引いた値を返します。
<br/>
 
llGetFreeMemory は開放されたメモリは考慮しません。まだ使われた事のないメモリの総量を返します。<br/>
llGetFreeMemory は開放されたメモリは考慮しません。まだ使われた事のないメモリの総量を返します。
<br/>
参考: [[LSL Errors/ja]] の "Script run-time error"、"Stack-Heap Collision" の項<br/>
参考: llGetFreeMemory が負の値を返す場合もある件について、その仕組みに関する [[Talk:LlGetFreeMemory]] における議論
|cat1=Script
|cat1=Script
|cat2=FixMe
|cat2
|cat3
|cat3
|cat4
|cat4
}}
}}

Revision as of 04:51, 13 May 2009

要約

関数: integer llGetFreeMemory( );

スクリプトが使用できる空きメモリのバイト数を integer で返します。

仕様

この関数のふるまいは、スクリプトが使っている仮想マシン (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 の使用例です: <lsl> integer free_memory = llGetFreeMemory(); llOwnerSay("割り当て可能な空きメモリが " + (string)free_memory + " KB あります。");

</lsl>

注意点

参考: LSL Errors の "Script run-time error"、"Stack-Heap Collision" の項

特記事項

LSO VM に関する注意点

この関数は空きメモリの量を返しません。この関数名は、理解の妨げになっています。LSL VM が Mono へ移行した暁には、この関数は再定義されるか、もっと有用な別の関数に置き換えられるかもしれないと言われています。

並列タスク/スレッド/プロセスで使われる典型的な Unix モデルに沿って llGetFreeMemory を簡潔に説明できます。すなわち、スクリプトのタスクが常に 16384 バイト (16 KB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。llGetFreeMemory は "ヒープが今まで一番下まで下がった地点" から "スタックの最上点" を差し引いた値を返します。

llGetFreeMemory は開放されたメモリは考慮しません。まだ使われた事のないメモリの総量を返します。

Search JIRA for related Issues

脚注

  1. ^ http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html
  2. ^ LSO VM の設計上、デフラグ関数は実現不能です。

Signature

function integer llGetFreeMemory();
この翻訳は 原文 と比べて古いですか？間違いがありますか？読みにくいですか？みんなで 修正 していきましょう！ (手順はこちら)
この項目はあなたにとって参考にならない項目ですか？もしかしたらLSL Wikiの関連した項目が参考になるかもしれません。
Retrieved from "https://wiki.secondlife.com/w/index.php?title=LlGetFreeMemory/ja&oldid=356813"