>>636
GCの未来を考えると、確かに、特定のアプリケーション領域に特化したメモリー確保やアライメントがあるわけで
tcmallocやhoardが低スレッド数では明らかにglibなどのmallocより速い事は、現状のシンプルな参照カウントが
絶対的に有利とはいえないね。GCであるない分類なんてどうでも良い話だわ

ちょっと前の話で出てきたUnity3Dで構築済みのオブジェクトをキャッシュして使いまわしパラレルGC（もっと
言えばS.T.W)を発生させないというテクニックも一歩前に進んで考えれば、都度のメモリー確保と破棄の時間を
省略し、さらに進めば複雑なオブジェクト構築に掛かる時間も部分的には省略可能なわけで、そこまでGC実装が
手が届くかはまだ疑問が多いが、今コンパイラにある最適化して実行速度を速めるフラグにはあまり使われない
バイナリーを小さくするトレードオフなフラグがあるが、メモリー効率を無視してより実行速度を高めるような
最適化を行うことを行いだしても不思議ではない。C系のコンパイラだとシステムコールや標準ライブラリには
厳密な意味があるのでメモリーの事前確保は難しいかもしれないが、他の言語でよくあるList構造なんかでは
それが必ずメモリー確保を必ず同期的に行うとは深く言及していない言語は、そのような道をたどるかもしれない。
tcmalloc/jemallocなんかもメモリプールを随分前に導入しているしね