K.Sasada's Home Page

PiGC : P/ECE 用ガベージコレクター


これはなに?

GC って知ってますか? ゲームキューブでもなく、グラフィックカードでもなく、ゴールドカードでもなく、ゴルフクラブのことでもなく、もちろんギコのことでもない、ガベージコレクション(Garbage Collection) のことですけど。詳しいことは Google ででも調べてください。

Boehm GC って知ってますか? malloc すると、勝手に GC をやってくれちゃいます。詳しいことは Google ででも調べてください。

この、Boehm GC っぽいことをするのがこの PiGC です。malloc するだけで、free が要りません。多分。

つまり、

mem = malloc(100);
while(mem){
	mem = malloc(100);
}

が、永遠にループするわけです。多分。

つかいかた

使いたいソースで、pigc.h を include してください。

また、プログラムに pigc.c をコンパイルした結果をリンクするようにしてください。要するに、pigc.c をプロジェクトに入れてください。

重要なことなんですが、アプリケーションの最初で pigc_init をよんでおいてください。

普通は pceAppInit で呼ぶのがいいでしょう。

そして、ヒープメモリが必要になれば、malloc をつかって下さい。free は要りませんが、別にやっても困りません。

ちなみに、P/ECE OS の仕様が変わると動かなくなるかもしれません。動くかもしれません。

また、新しいバージョンではpceHeapAlloc を利用しなくなりましたので、某バグに悩まされること無く 1バイトからの malloc が可能です。お奨めしないけど。

だうんろーど

こちらからどうぞ。

test ディレクトリで、簡単なテストプログラムをおいてます。


ライセンスは、ライセンスは。Rubyと同じ、とか言うとこの場合アレっぽいので独自に・・・。

であれば、あとはお好きに。

できれば、

を教えていただけると嬉しいです。

どれくらいすごいの?

2000 個の要らんオブジェクトを作って、GC を発生させると、60ms くらいかかります。10個くらいだと 20ms くらい。テスト環境での評価ですけど。

どうやってんの?

保守的 mark & sweep でやってます。

マークするための領域として、このライブラリでは 2KB のテーブルを利用します。

ヒープ管理は基本的に P/ECE 標準の pceHeap* に任せています。

マークフェーズを、実は 16バイト間隔でやってます。4バイト境界(これで十分なんですけど)にすると、マーク用のテーブルが 8KB になるのですよ。まぁ、16バイトなら大丈夫かな、と。多分。

フリーする部分は、pceHeapFree を使うと遅いので、自分でかわりにやってます。

Boehm GC と同じような感じだと思うんですが、ソース見てないからよくわかんないです。いや、落としたんだけど、どこを見ればいいかわからんかった。

まぁ、細かいことはソースを見てください。250行ほどなので簡単です。

なんでつくったの?

GC作ったこともないくせに、言語処理系を語るのかよ、とか言われるのがいやなので。練習です。

もうちょっとすごいつかいかた

malloc() 、gcmalloc() で GC対象になるメモリを確保します。

nongcmalloc() で確保したメモリは GC対象になりません。

この辺は、うまく使い分けてください。

また、pigc_setflag(void *mem,int flag) で、確保したメモリをGC対象にするかしないかを後で設定することができます。flag に 0, 1, 2 とすることでそれぞれ 現在の設定を見る、GCしない、する、とすることができます。


マクロ PIGC_DEBUG が定義されていると、Pigc_DebugInfo によって、PiGC のデバッグ情報を取ることができます。

マクロ DEBUG が定義されていると、USBによってPC側に情報を出力するようになってますけど、この辺は私の趣味です。これとかはあとで公開しときます。

同梱のMakefileで作られるのは、PiGC をつかったテストとなります。freeしないでmallocしつづけますけど、止まりません。多分。

まぁ、ヒープが 200KB 使えるとしたら、100KBはGCによって消せる状態であるといいと思われます。200KB いっぱいいっぱい使っていれば、GCが出来なくて結局メモリは足りなくなります。

ちょっと、まじめに

開発話。

いや、最初はすげー簡単にできるんだと思ってたんですよ。その理由として、P/ECE では、

ヒープ管理がわかれば、それを利用することができます。

ヒープとスタックがわかれているので、ヒープが一杯の状態でも、平気でスタックを使うことができます。

んで、やってみたら、マークする方法で悩んだ悩んだ。P/ECE ではヒープ管理を単方向連結リストによって行っていますが、これだと、マークをつけてもいいのか悪いのかわからない。

しょうがないのでテーブルを用意しました。しかし256KBしかメモリが使えない P/ECE に大きな容量が


本音。

使わないよなぁ。こんなの。

そもそも、P/ECE のアプリケーションで、ヒープのメモリを利用する機会がどれほどあるものか、と。

ヒープ関係は遅いです。リアルタイム処理能力が要求される、アクションゲームなどではなかなか使えないでしょう。グローバル変数とかでちゃっちゃうとか。

言語処理系(インタープリタ)とかを作るのならば、PiGC をつかってもいいですが、性能を求めるなら、その処理系の特質にあったメモリ管理方式を考えれば十分です。うん。多分。少なくとも私ならそうする。

んで、PiGC のGC時間は60ms とかいってますね。50FPSで3フレーム分です。3フレームが、なげーと感じてしまうゲームでは使えません。これじゃ。

というわけで、PiGC の用途は、リアルタイム性を求めないテーブルゲーム系とかですかね。そのへんの思考ルーチンのための言語処理系、とか。

追記

言語処理系ならば、それなりに使えるかもしれない。それなりに簡単に使えるし。P/ECE 程度のメモリ領域なら、いちいちそんなことしないでもいいし。うん。というわけで、それなりに使えるかもしれんぞ、ってことで。使ってみてください。

みておくべきもの

参考資料です。

なにがかわったの?

$Id: pigc.html,v 1.1 2003/04/28 10:27:52 ko1 Exp $

Sasada Koichi / sasada@namikilab.tuat.ac.jp
$Date: 2003/04/28 10:27:52 $