All About Libpas, Phil's Super Fast Malloc
Are there any projects that surgically augment the memory APIs to be more cooperative? Sure `malloc` implementations will make various tradeoffs, but what if the malloc&#x2F;free APIs were expanded to expose more programmer-intent or cooperative defrag, etc?<p>- Perhaps `malloc` could ask for an intended lifecycle (think GC generation) that could swap arenas or other algo internals. This opens us up to meta-allocators.<p>- Perhaps program lifecycle hooks that give allocators more context into how already-allocated memory intends to be accessed. (&quot;Done bootstrapping the server, so now new memory will be accessed by single threads and only live for one request&quot;, etc)<p>- Perhaps the programmer could periodically call `remalloc` to allow objects to be moved or promoted between arenas&#x2F;generations.<p>- Perhaps mallocs&#x2F;frees could be more intelligently batched (where explicit structs&#x2F;arrays don&#x27;t normally make sense) for surprise-free defrag or OS allocation.<p>- Intelligent pairing of malloc&#x2F;free with explicit notions of intended re-use; some indication of &quot;I will free this and ask for the same memory again in the same call&quot; or auto-struct-ing mallocs which know that we tend stack malloc(foo);malloc(bar);free(bar);free(foo). Avoid any actual OS&#x2F;memory involvement whatsoever.<p>- Perhaps `identmalloc` could handle common flyweight patterns of instantiate-unless-exists; e.g. intelligently turn shared state into offsets into a contiguous arenas. This may be more useful in C++ with existing conventions around copy-by-value constructs.<p>Some of these are indeed components of existing mallocs&#x2F;allocators (e.g. libpas is type-aware), but my point is that allocators have to jump through hoops to derive heuristics, and these heuristics often amount to &quot;the programmer often intends to use memory like X.&quot; Performance engineers then pattern-match for X rather than cooperating with the compiler to expose X intrinsically from the beginning. The above ideas impose <i>slightly</i> different programming paradigms, so there&#x27;s still the white wale of a perfect drop-in heuristic, but it seems less subject to temporary or local maxima.<p>So: Are there compelling (albeit slightly less general-purpose) alternatives where the allocator and programmer communicate additional hints or other API contracts that allow the allocator to move away from heuristics and into proven patterns? Or is this basically akin to &quot;use c++&#x2F;smart pointers or just get a gc&quot;?