GDCメモ

クラスをfoo.dというファイルに記述し、main.dでfoo.dに記述されたクラスを インスタンス化して使用するような場面は普通にあります。この時、クラスの 内容を変更したのでfoo.dをコンパイルしてfoo.oを生成し、main.dには 変更が加わっていないので リコンパイルしてないmain.oを使用すると、リンクでエラー する事無く、実行ファイルが生成されてしまうことがあります。所が実行すると いきなりSegmentation fault でずっこける場合があります。 特に、makeを使って変更のあったファイルだけをコンパイル対象にしていると陥ります。 一度make cleanした後、makeし直してみれば、恐らくmain.dを コンパイルした時に、メソッドの引数が違っているなどのエラーが出るので気づくでしょう。

Phobosのガベージコレクタ(GC)は「ConservativeGC(保守的GC)」を採用しています。 この方式ではスタック上の値を全てメモリへのポインタとみなしています。もしGCで管理して いるメモリ領域を指している場合はメモリ回収の対象にしません。 例えば、次のようなコードでは未使用となっているハズのメモリが回収されません。

//
// GCされない例
//
import std.stdio ;

class Storage{
  private byte[] array ;
  this(int size){
    array.length = size ;
  }
}

int main(string args[])
{
  Storage   storage ;
  int[4096] adlist ;

  for( int i=0 ; i<adlist.length ; i++ ){
    adlist[i]=0x00100000*i ;
  }

  writef("===loop start===============================================================\n") ;
  for( int i=0 ; i<4096 ; i++ ){
    storage = new Storage(0x00100000) ; //(i>0)の時(i-1)で確保したインスタンスは未使用になる
    core.memory.GC.collect() ;
  }
  writef("===loop end=================================================================\n") ;

  return(0) ;
}

この例では、スタック上に確保される静的配列 adlistに1MBおきの(ポインタではない)単なる値を保持しています。 ここで 1MB以上のメモリを確保すると、adlistの値のいずれかが必ず確保したメモリブロック を指してしまう事になります。この為、実際には未使用になっているメモリ領域 内を指している値があると判断して、そのメモリ領域は回収の対象にならないという流れです。 解決方法はいくつか考えられます。

• adlistをスタック上に確保される静的配列ではなく動的配列に変更する。
• 確保した領域が不要になったと判断できる所で、明示的にdelete文で 開放する(C言語で言うところのmalloc()に対応するfree()を実行する感じでしょうか)。 このとき、例で言うと クラスStorageのデストラクタに「delete array ;」を加える必要があります。 core.memory.GC.collect() ;の手前に「delete storage ;」を加えるだけでは足りません。 インスタンス自体は削除されますが、そこから参照しているarrayまで開放するという意味には ならないからです。

これはGDCだけでなくオリジナルのDMDでも言える事です。

DLL内関数とリンクをする際、単純にextern(C)で宣言するとリンクに失敗します。 extern(Windows)宣言するとリンク可能になります。 かなり古いGDCではextern(Windows)宣言が使用できませんでした。その為、 C言語で書いたラッパーを噛ませて、リンクする必要がありました。

DMDのWindowsアプリを書く例の通りにすると、何故かうまく動いたり動かなかったり 挙動不審な実行ファイルが生成されました。WinMainで始めると、スレッド自体が ガベージコレクタの管理下に無い状態で実行されるようで、ガベージコレクタの 管理が壊れてしまう場合があるようです。単一スレッドで動作する事を保証する為に、 main()内でメッセージループを回すという方法で安定して動作するようになりました。

メッセージを受け取るプロシージャ関数はextern(Windows)宣言する必要があります。 WNDCLASSのlpfnWndProcメンバーに WNDPROC型で入れる場合、キャストすると それとなくコンパイルできてしまうのですが、動かない実行ファイルができあがります。

WM_PAINTメッセージ処理に於いて、PAINTSTRUCT 変数を使用するのは定石なのですが、 一時変数として使用する際、static宣言する必要がありました。

case WM_PAINT:
       static PAINTSTRUCT ps;
       hdc = BeginPaint(hwnd, &ps);
        :
       EndPaint(hwnd, &ps);
       break ;

static宣言が無いと、動いたり動かなかったりする場合もあれば、動かない場合に Windows98ではシステムフリーズしてしまうという致命傷に陥りました。

2010/11/03追記:

スレッド生成の方法がまずかったのが原因だったのだろうと思われます。 (gdc 0.24, using dmd 2.014)ではひとまず問題無さそうです。 逆にstatic宣言すると複数のインスタンスで共用されてしまいますので、 マズい場合があるかも知れません。