LUA 5.1 の GC

『毒々マンボウ後悔記』より．

Lua 側では本当にメモリの確保時も解放時もヒープに関しては考慮してない。即座に確保*3、即座に解放。てっきり Lua 内部でもちっこいメモリはプールするくらいのことはやってるモンだと思ってたから意外だった。まあ、下手なヒープを内部に作るよりはユーザープログラムに全部投げしちまおう、みたいなコンセプトなんだろうね。だって Lua だし。lua_Alloc にログ仕掛けたら結構壮快。実際に動かすなら単純な Segregated なフリーリストくらい用意した方が良いかもね。

あと、Sweep フェイズの解放するオブジェクト数の上限とかもユーザープログラムから制御できるようになってれば良いのに、と素人目には思いました、まる

そういえば Microsoft は開発環境と OS を両方提供する強みというか，Visual C++ のヒープ管理部分を出来る限り薄くして OS 提供のヒープマネージャに丸投げするようにしてますね．この方式のメリットは OS のバージョンアップで今後も高速化する余地を残しているところで，実際過去何度か「ヒープマネージャの高速化」が新 OS のうたい文句に使われてきたかと思います．
この方式は「メモリ周りにバグを抱えるアプリケーションが OS のアップグレード時に (ヒープマネージャのアルゴリズムが変更されたために)動かなくなる」という副作用を持っていますが，長い歴史の中で「アプリケーション単位で API の動作を変える」という涙ぐましい抗体反応を獲得した Windows は，有名アプリケーションについてはこの問題を表面化させずに済んでいます．例の Simcity Hack の話は有名(id:NyaRuRu:20040703#p1)．