The problem of how to make a scalable malloc is fairly well-understand at this point; the problem of fragmentation is essentially unsolvable. If the lifetime of objects is known statically, then the problem can solved by providing extra information to the allocator, either manually, or through hints from the compiler. So far such hints have not been forthcoming.

Jeff, thread safety is important, but independent of this. Locking costs can be spread out over many calls to malloc() so that they end up being smallish. TcMalloc certainly does this; I don’t know about glibc or MS CRT.

(Hard to imagine why glibc wouldn’t–maybe the fixed cost is considered too high?)

Locality can be a big deal. On average, a page fault is many times worse than passing through a mutex. Unless there’s contention, a single cache miss is probably comparable to a mutex. Worst-case locality means your system thrashes.

(It’s possible that TcMalloc’s microbenchmark generates a lot more contention, and fewer memory accesses, than real-life usage would. I have not looked at it.)