Const flags describing allocator properties

[the8472]

It would be useful if allocators had an associated constant of flags describing their properties, such as

• support for alignment-changing realloc (posix realloc doesn't, jemalloc does)
• does realloc try to avoid memcpy (doing virtual memory schenanigans)
• whether deallocation does anything (vs. an arena that drops all allocations at once)
• support for zero-length allocations
• if alloc_zeroed is any different from allocate
• do realloc/dealloc care about the layout information being correct
• etc.

Containers can then choose to optimize their behavior based on those properties.

(from #120 (comment))

[Amanieu]

Can you give examples of how generic code (e.g. Vec) could make use of these properties?

[the8472]

support for alignment-changing realloc

Would allow the in-place collect code in vec to apply in more cases.
Currently GlobaAlloc does this: https://doc.rust-lang.org/nightly/src/alloc/alloc.rs.html#302-321
which means shrinking efficiency depends on the layouts, but some allocators can do better than that

does realloc try to avoid memcpy

can help picking between new-allocation-and-grow vs. reuse-allocation-and-shrink strategies. I.e. when shrinking incurs memcpy costs then it's better to use a fresh allocation from the beginning.

It would also let us pick between realloc vs. alloc-manually-copy-dealloc when there's a huge discrepancy between capacity and length.

do realloc/dealloc care about the layout information being correct

lets in-place-collect skip some realloc calls

whether deallocation does anything

for non-drop T we can turn Container's Drop into a noop

And that's just examples. The list should be extensible of course. Flags would need to have conservative defaults.

[the8472]

Another useful property would be if the allocator could indicate support for zero-sized allocations, e.g. by always returning NonNull::dangling.
With this knowledge we would be able to optimize out some branches in alloc code that check the requested allocation size and always call the allocator instead. This would simplify things for LLVM since it would see a straight, branch-free path from allocation, use, deallocation, which can help optimizing temporaries