Latest topics > js-ctypesで期待した通りにガーベジコレクトされてくれないから自分でmalloc/freeする

js-ctypesで期待した通りにガーベジコレクトされてくれないから自分でmalloc/freeする - Mar 27, 2011

最初に要点だけまとめておくと、

• js-ctypesを使う時は、JavaScriptのコード側では基本的にメモリの管理のことは考えなくてもいい（ガーベジコレクト任せにしていい）事になってる。
• しかし実際使ってみると、JavaScriptからjs-ctypes経由で自分でmalloc/freeしないとどうにもならないという場面があるみたい。
• なのでJavaScriptからjs-ctypes経由でmalloc/freeする方法とその実例を紹介する。

という話です。

js-ctypesで使ったメモリが解放されない事がある

JavaScriptでは変数は動的に定義する物なので、可変長の配列なんかも全然何も考えずに使えます。必要なメモリは実行時に勝手に確保されて、使われなくなったらガーベジコレクタがそれを勝手に回収（解放）してくれる、というモデルです。

それに対して、C言語では配列は必ず長さが決まってないといけなくて、可変長の配列のように実行時にデータの量が決まるような変数を使いたい場合は、malloc()でメモリを確保して使い終わったらfree()で解放するという事をしないといけません。

js-ctypesはJavaScriptからCのライブラリを呼ぶ物なのですが、ではメモリの確保とかの話はJavaScript側とC側のどっち寄りなのか？　というと、これはJavaScript寄りになります。Cのライブラリに渡すために定義した変数のために必要なメモリ領域はその場で自動的に確保されて、使い終わった変数のメモリ領域は勝手に解放されるようになってます。

……ということになってるんですが、実際には期待した通りにメモリが解放されてくれない事があるようです。1つ前のエントリのケースがまさにそうだったのですが、動的に構造体を定義してそのインスタンスを作って……ということをやっていると、関数が呼ばれるごとに消費メモリが増えていって、メモリリークっぽい状態になってしまいました。

以下が問題の箇所です。

var selfUsage = 0;
var pagesCount = self.NumberOfEntries;
if (is64bit) pagesCount = pagesCount * 2;
var PSAPI_WORKING_SET_INFORMATION = new ctypes.StructType
    ('PSAPI_WORKING_SET_INFORMATION', [
        { NumberOfEntries : ULONG_PTR },
        { WorkingSetInfo  : ctypes.ArrayType(ctypes.uint32_t, pagesCount) }
    ]);
// ここでメモリが確保されてる
var actualSelf = new PSAPI_WORKING_SET_INFORMATION();
if (QueryWorkingSet(GetCurrentProcess(),
                    actualSelf.address(),
                    PSAPI_WORKING_SET_INFORMATION.size) != 0) {
  let pages = actualSelf.WorkingSetInfo;
  let step = is64bit ? 2 : 1 ;
  for (let i = is64bit ? 1 : 0; i < pagesCount; i += step) {
    if (!(pages[i] & 0x100)) {
      selfUsage++;
    }
  }
  selfUsage = selfUsage * systemInfo.dwPageSize;
}

// ここで参照を消してるのにGCされない
actualSelf = undefined;
PSAPI_WORKING_SET_INFORMATION = undefined;

自動でガーベジコレクトされてくれないということは、どっかに参照が残ってしまっててるのか？　と思ってコードを見直してみてもそういう事は全然無いし、第一Components.utils.forceGC()で強制的にGCしてみたらちゃんと消費メモリが減ります（つまり、本当の意味でのメモリリークではないということです。「メモリリークっぽい」と書いたのはそのためです）。

また、GCは一般に重たい処理と言われているので、消費してるメモリの量が一定以上にならない限りは自動ではGCされないのかな？　とも思ったのですが、ほっとくとFirefoxの消費メモリが1.8GBとかあり得ないことになったりもしてました。これはどう考えても、そろそろGCするべきだろという時機を逸してしてしまってるとしか思えません。

どうも、js-ctypesとJavaScriptの自動GCは相性が悪いようで、js-ctypesを使ってる時は期待されるようなタイミングで自動的にGCが走ってくれないという事が起こるようです。

対策

この問題に対する対策の方法は2つあります。

• Components.utils.forceGC()で強制的に頻繁にGCさせる。
• GCに期待しないで自分でメモリを管理する。

前述した通り、Components.utils.forceGC()を呼ぶとその時点での消費メモリ量やCPUの忙しさとかに関係無く、強制的にGCを走らせる事ができます。実際に、getMemory()を実行した時に一緒にComponents.utils.forceGC()も実行するようにすると、メモリ消費がぐんぐん増えていくというメモリリーク様の症状はぱたりと発生しなくなりました。

が、これは弊害が大きそうなのでできれば避けたい所です。これも前述した通りですが、GCは結構重い処理だそうなので、GCが走る瞬間は動画の再生が止まるなどの問題が起こりる事があります。システムの状態を表示するだけのアドオンなのに、それを入れてると1秒ごとに動画の再生が止まってしまうとか、ちょっとあり得ないです。

GCに期待しないで自分でメモリを管理するというのは、

1. js-ctypesで定義した構造体をJavaScriptでnewする。
2. Cの側で自動的に必要なメモリ領域が確保され、その領域がJavaScriptのGCの管理対象になる。
3. 必要な処理を行う。
4. 処理が終わったので、JavaScriptでnewした構造体への参照を削除する。後のことはGCに任せる。
5. （期待した通りに動いていれば）GCが走り、JavaScriptでどこからも参照されていない変数が自動的に検出されて、メモリが解放される。その時、2で確保されたメモリ領域も一緒に開放される。

というのをやめて、

1. js-ctypes経由でJavaScriptからmalloc()を呼ぶ。
2. Cの側でmalloc()が呼ばれ、必要なメモリ領域が確保される。この時、malloc()で確保されたメモリ領域そのものはGCの管理対象にならない。
3. malloc()の戻り値であるポインタをjs-ctypes経由でJavaScriptに返すために必要なメモリ領域がCの側で自動的に確保され、その領域がJavaScriptのGCの管理対象になる。
4. 必要な処理を行う。
5. 処理が終わったので、JavaScriptからfree()を呼ぶ。2で確保されたメモリ領域が開放される。
6. JavaScriptで、ポインタが格納された変数への参照を削除する。
7. （期待した通りに動いていれば）GCが走り、JavaScriptでどこからも参照されていない変数が自動的に検出されて、3で確保されたポインタのために必要なメモリ領域が解放される。

という風にするということです。GCが走らなければこれでもjs-ctypesのポインタ型の変数のために確保されたメモリ領域の分だけ消費メモリは増えていってしまいますが、消費されるメモリの量は桁違いに少ないと考えられますので、こっちの方がマシに自分には思えました。

malloc/freeをどうやって呼ぶ？

js-ctypesは、ライブラリを開いて関数を定義してという手順で使う関係上、.dllや.soや.dylibといったライブラリを必ず開かないといけません。システムコールでもCの標準ライブラリの機能でも、この手順に則る必要があります。malloc()やfree()も例外ではありません。(この辺はjs-ctypesが機能として持っててくれてもいいと思うんですが、残念ながらそうはなっていません……）

ところで、MozillaのCのコードではCのmalloc()やfree()を直接呼ぶ代わりに、PR_Malloc()やPR_Free()という関数を使うようになってます（インターフェースはC標準のmalloc/freeと同じですが、malloc/freeで引数の型がsize_tになっている所が、これらのPR_なんちゃらではPRUint32になってるという点が異なります）。ということは、Firefox本体のバイナリには必ずこれらの関数が含まれているという事なので、それを呼んでやればどんな環境でも確実にmalloc/freeできると言えます。

実際にオープンするファイルはNSPR（Netscape Portable Runtime）のバイナリで、これはWindowsではnspr4.dll、Linuxではlibnspr4.so、Mac OS Xではlibnspr4.dylibというファイル名になっています。以下は、それらを自動的にオープンしてメモリ確保関係の関数を定義する例です。

const Cc = Components.classes;
const Ci = Components.interfaces;

Components.utils.import('resource://gre/modules/ctypes.jsm');

const OS = Cc['@mozilla.org/xre/app-info;1']
            .getService(Ci.nsIXULAppInfo)
            .QueryInterface(Ci.nsIXULRuntime)
            .OS.toLowerCase();

// プラットフォームごとに適切なライブラリを開く
const gNspr4 = OS.indexOf('darwin') == 0 ?
                ctypes.open('libnspr4.dylib') :
            OS.indexOf('linux') == 0 ?
                ctypes.open('libnspr4.so') :
            OS.indexOf('win') == 0 ?
                ctypes.open('nspr4.dll') :
            undefined ;

if (typeof gNspr4 == 'undefined')
    throw new Error('unknown platform');

const PR_Malloc = gNspr4.declare(
        'PR_Malloc',
        ctypes.default_abi,
        ctypes.voidptr_t,
        ctypes.uint32_t // size
    );

const PR_Calloc = gNspr4.declare(
        'PR_Calloc',
        ctypes.default_abi,
        ctypes.voidptr_t,
        ctypes.uint32_t, // nelem
        ctypes.uint32_t // elsize
    );

const PR_Realloc = gNspr4.declare(
        'PR_Realloc',
        ctypes.default_abi,
        ctypes.voidptr_t,
        ctypes.voidptr_t, // ptr
        ctypes.uint32_t // elsize
    );

const PR_Free = gNspr4.declare(
        'PR_Free',
        ctypes.default_abi,
        ctypes.void_t,
        ctypes.voidptr_t // ptr
    );

実例

これを使って先の例を書き直すと、以下のようになります。

var selfUsage = 0;
var pagesCount = self.NumberOfEntries;
if (is64bit) pagesCount = pagesCount * 2;
var PSAPI_WORKING_SET_INFORMATION = new ctypes.StructType
    ('PSAPI_WORKING_SET_INFORMATION', [
        { NumberOfEntries : ULONG_PTR },
        { WorkingSetInfo  : ctypes.ArrayType(ctypes.uint32_t, pagesCount) }
    ]);
// メモリを確保する。
var actualSelf = PR_Malloc(PSAPI_WORKING_SET_INFORMATION.size);
// 固定長の構造体へのポインタにキャストする。
var actualSelf = ctypes.cast(self, PSAPI_WORKING_SET_INFORMATION.ptr);
if (QueryWorkingSet(GetCurrentProcess(),
                    // 既にポインタなので「.address()」は不要。
                    actualSelf,
                    PSAPI_WORKING_SET_INFORMATION.size) != 0) {
  // ポインタが指しているデータの内容にアクセスするには
  // 「.contents」を使う。
  let pages = actualSelf.contents.WorkingSetInfo;
  let step = is64bit ? 2 : 1 ;
  for (let i = is64bit ? 1 : 0; i < pagesCount; i += step) {
    if (!(pages[i] & 0x100)) {
      selfUsage++;
    }
  }
  selfUsage = selfUsage * systemInfo.dwPageSize;
}

// メモリを解放する。
PR_Free(actualSelf);
actualSelf = undefined;

先の例と見比べると、どこを書き換えたかが分かりやすいと思います。

PR_Malloc()やPR_Calloc()で確保した領域は自動的なGCの管理対象外になるので、PR_Free()で解放しないとこれはほんとにメモリリークになります。そうなるとComponents.utils.forceGC()でもメモリが解放されなくなるので、freeは絶対に忘れないでください。というか、GCがちゃんと走るようなケースであればそっちに任せておいた方がいいです。今回の事例のように、何故かどうしてもGCが走ってくれないという場合の緊急避難と考えておいた方がいいでしょう。

GCがあるからメモリ管理のことを気にしなくていいはずのJavaScriptでこんな事をやってるというのが、だいぶ意味不明でウケますね。

分類：Mozilla > XUL, Firefox, JavaScript, js-ctypes, Mozilla, XUL , 時刻：06:42 | Comments/Trackbacks (2) | Edit

ツイート