2008年3月に考えたプログラミング的事項 - プログラミングの作業に何の価値も見出せなくなってしまったd金魚による日記

　GCってうまく組まないとセキュリティーホールになりやすいかも。
http://video.google.com/videoplay?docid=-8961819826231183931
より思ったこと

　もう手続き型言語とか関数型言語でプログラム組むのはやめたい。Xという機能を実現する関数に値を渡したら実装は全部自動でやって欲しい。まるでconfigureの如く･･･。たとえばJavaなんかはどのOSでも動くように組まれているように･･･。今ある方法よりもっともっと抽象化してプログラミングを行いたい！

　アプリケーションの最適なメモリ管理に必要と思われる事項
・利用可能な物理メモリ領域（アプリケーションがOSに返していないメモリ領域を返却する指標にする）
・全物理メモリ領域
・アプリケーションが利用可能なメモリ領域（事前に確保していたメモリが残りはいくらか）
・

　昔から考えている変なコンテナのデータ構造のメモ
・イテレーションできます。
・push_back(), pop_back(), push_front(), pop_front()できます。
・メモリコンパクションできます。
・ひとつのメモリプールは「レジスタのビット数」からなる（32個や64個）
以下擬似データ構造　これを１とする。

template<typename DATA>
struct{
 register_uint flag
 DATA data[register_uint_length];
};

・１を必要と思われる分だけ用意します。

・空いている部分をキャッシュしているので空いている部分を探すことが必要ありません。
空いている部分のフラグのパターン
「沢山データが詰まっているグループ」　　フラグのビットパターン例：11101
「データ詰まっていないグループ」　　　　フラグのビットパターン例：00100
に分ける。
それらの集合にそれぞれ「レジスタのビット数」で分ける部分を持たせる
例：
0の配列の添え字が空いている所
...
32の配列の添え字が空いている所

・データが詰まっていないグループから沢山データが詰まっているグループへデータを移動することによってコンパクションを図ります。その時にイテレーターが無効になります。

　メモリを管理する場合、スレッドの管理も同時に行わなければスマートな整合性やタイミングが取れない･･･。と言うことで、メモリ管理機能をOSから独立したアプリケーション層で作るならばメモリ管理機能と複雑に絡み合った？（要考慮）スレッド管理機能も作らなくてはならない。
　固定長メモリプールと可変長メモリプールは内部でのメモリ管理のやり方が違う。可変長の場合、チェックする項目が多くなり遅くなりそう･･･。あえて可変長を作ってそれをもとに固定長メモリプールにするか･･･　いや、それだと遅くなりそう･･･。いや遅くなる。そういった条件のみを書き下してスクリプト組んで各ソースコードを吐いてもらうか･･･。
　そういえば昔、Kernel読書会でmallocの実装についての発表があったはず･･･
http://d.hatena.ne.jp/studiokingyo/20060929#p3
それに関係する記事。
http://0xcc.net/blog/archives/000112.html
http://www.radiumsoftware.com/0311.html#031101
なんというか、glibc malloc(dlmalloc)のチューニングぶりを見る限り、メモリ管理機構は作らなくても良いんじゃないですか？と思ってしまいました。となると可変長メモリプールではなく固定長メモリプールの開発のみに的を絞ったほうが良いのではないかと･･･。