@RichFelker Not at all the same. Uninitialized data access and out-of-bounds reads (especially one element past the end) are very common.
@CopperheadSec % overhead is fairly inconsequential. Large O(1) overhead sucks. n->0 asymptotics matter as much as n->∞. (e.g. 4 lg nprocs).
-
-
@RichFelker The region alignment design provides cheap, low-overhead metadata. There's pressure for larger regions for various reasons. -
@RichFelker Allocations smaller than the region size aren't ever aligned to the region size and have their metadata in the region header. -
@RichFelker Other allocations are a multiple of the region size, so their minimum alignment is the region size. Need real data structures. -
@RichFelker So there's a pressure to raise the size because it's inherently faster and more parallel to manage allocations within regions. -
@CopperheadSec There's no sense in optimizing for speed of allocations larger than small_const*memset_rate*malloc_time. -
@CopperheadSec This is because you can assume any reasonable caller actually _uses_ the amount of mem it allocs, and use takes > memset_time -
@CopperheadSec This is why I have no interest in avoiding mmap for lg (>128k) allocs - memset(128k) is much slower than mmap. -
@RichFelker Using mmap, mprotect and munmap grabs the global mmap_sem writer lock though, and that hurts. Even madvise calls get blocked. - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.