Difference between revisions of "LlGetFreeMemory/ja"

From Second Life Wiki
Jump to navigation Jump to search
m (Add {{Help/Old_Info/ja}})
 
(7 intermediate revisions by 5 users not shown)
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 の場合の戻り値は、ガベージ コレクションに先立ってスクリプトが使用可能な空きメモリの量です。これは即ち、ガベージ コレクション間近のメモリは、スクリプトに割り当てられた 64KiB を丸々利用できる状態にはない事を意味します。付け加えると、Mono は LSO VM 程にはメモリの制約が厳しくなく{{Footnote|http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html}} (LSO は 16KiB 以上のメモリは利用<u>不可能</u>でした)、結果的により多くの空きメモリを利用できます。
===LSO===
LSO の場合の戻り値は、ヒープ領域としてまだ使われていない、スタック領域が使用できる空きメモリの量です。
LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。
LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。


{{LSLG/ja|string}}、{{LSLG/ja|list}}、{{LSLG/ja|key}} はヒープに格納されます。ヒープ ({{LSLG/ja|string}}、{{LSLG/ja|list}}、{{LSLG/ja|key}}) のポインタ、{{LSLG/ja|integer}}、{{LSLG/ja|float}}、{{LSLG/ja|vector}}、{{LSLG/ja|rotation}} はみなスクリプトの実行時、一時的にスタックに格納されます。
{{LSLG/ja|string}}、{{LSLG/ja|list}}、{{LSLG/ja|key}} はヒープに格納されます。ヒープ ({{LSLG/ja|string}}、{{LSLG/ja|list}}、{{LSLG/ja|key}}) のポインタ、{{LSLG/ja|integer}}、{{LSLG/ja|float}}、{{LSLG/ja|vector}}、{{LSLG/ja|rotation}} はみなスクリプトの実行時、一時的にスタックに格納されます。


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


ヒープにはフラグメントが生じることがあり、そこには使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが、フラグメントを抑制するコツはあります。
ヒープにはフラグメントが生じることがあり、そこには (個々のサイズが小さいゆえ) 使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが{{Footnote|LSO VM の設計上、デフラグ関数は実現不能です。}}、フラグメントを抑制するスクリプト上のテクニックはあります。
|caveats=
|caveats=
*ヒープが使用可能な空きメモリは、これより多いかもしれません。(少なくともこれ以下ではありません。)
*ヒープが使用可能な空きメモリは、これより多いかもしれませんが、少なくはありません。
|constants
|constants
|examples=
|examples=
以下は llGetFreeMemory の使用例です:
以下は llGetFreeMemory の使用例です:
<lsl>
<source lang="lsl2">
integer Ki = 1024; // 1024 == (1 << 10);
integer free_memory = llGetFreeMemory();
float maxPerScript = 16 * Ki;
llOwnerSay("割り当て可能な空きメモリが " + (string)free_memory + " バイトあります。");
llOwnerSay((string) ((maxPerScript - llGetFreeMemory())/Ki) + " KB のメモリがスクリプトのリセット後に一回以上使われました。");
</source>
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>
|helpers
|helpers
|also_functions
|also_functions=
{{LSL DefineRow||[[llGetUsedMemory/ja|llGetUsedMemory]]|}}
{{LSL DefineRow||[[llScriptProfiler/ja|llScriptProfiler]]|}}
|also_events
|also_events
|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 KiB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。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
}}
}}

Latest revision as of 20:44, 4 August 2021

要約

関数: integer llGetFreeMemory( );

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

仕様

この関数のふるまいは、スクリプトが使っている仮想マシン (Virtual Machine, VM) に依存します。Mono は新しい VM、LSO はその前の古い VM です。Mono と LSO の大きな違いは、Mono はスクリプトの実行速度が速く、また使えるメモリが 4 倍ある事です。

Mono

Mono の場合の戻り値は、ガベージ コレクションに先立ってスクリプトが使用可能な空きメモリの量です。これは即ち、ガベージ コレクション間近のメモリは、スクリプトに割り当てられた 64KiB を丸々利用できる状態にはない事を意味します。付け加えると、Mono は LSO VM 程にはメモリの制約が厳しくなく[1] (LSO は 16KiB 以上のメモリは利用不可能でした)、結果的により多くの空きメモリを利用できます。

LSO

LSO の場合の戻り値は、ヒープ領域としてまだ使われていない、スタック領域が使用できる空きメモリの量です。

LSL のメモリ空間は "バイト コード", "スタック", "空きメモリ", "ヒープ" の 4 領域に区分されます。空きメモリとは割り当てを受けていないメモリの事で、スタックとヒープの間にある領域の事です。4 領域を全て合計したサイズは 16384 バイトです。

string、list、key はヒープに格納されます。ヒープ (string、list、key) のポインタ、integer、float、vector、rotation はみなスクリプトの実行時、一時的にスタックに格納されます。

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

ヒープにはフラグメントが生じることがあり、そこには (個々のサイズが小さいゆえ) 使用不能なメモリ ブロックが含まれる事になります。デフラグを行なう関数はありませんが[2]、フラグメントを抑制するスクリプト上のテクニックはあります。

警告

  • ヒープが使用可能な空きメモリは、これより多いかもしれませんが、少なくはありません。
All Issues ~ Search JIRA for related Bugs

サンプル

以下は llGetFreeMemory の使用例です: 

integer free_memory = llGetFreeMemory();
llOwnerSay("割り当て可能な空きメモリが " + (string)free_memory + " バイトあります。");

注意点

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

関連項目

関数

•  llGetUsedMemory
•  llScriptProfiler

特記事項

LSO VM に関する注意点

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

並列タスク/スレッド/プロセスで使われる典型的な Unix モデルに沿って llGetFreeMemory を簡潔に説明できます。すなわち、スクリプトのタスクが常に 16384 バイト (16 KiB) のメモリを保持しているとします。バイト コードとスタックは下から上へ、ヒープは上から下へ伸びてゆきます。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=1210211"