Is there ever a situation (with modern mallocs) where realloc() does something that you can’t just do with malloc_size()? It really seems like an attractive nuisance at this point.
Conversation
Replying to
realloc can grow an allocated block into free space available after it, whereas malloc_size will only tell you the size of the allocated block, right? (Or are you saying modern mallocs don't actually do this?)
1
1
Replying to
Modern mallocs bucket by size, so are rarely going to be able to expand except into the rest of the current bucket, and malloc_size tells you how much room you have there.
1
Performance-oriented allocators like jemalloc and many others manage the memory for large allocations beyond their slab allocation size classes. They can still do real in-place growth. Being able to take advantage of mremap to move pages rather than using memcpy also helps a lot.
1
2
Using mremap is particularly helpful when combined with larger page sizes. Transparent huge pages combined with the allocator aligning to the huge page size makes mremap extremely advantageous. There's per-process global locking for mremap but at huge sizes it's a major win.
The malloc_object_size API is non-standard and is seriously flawed. It's undefined behavior to use more of the allocation than you requested. It's a real problem with both Clang and GCC due to the alloc_size attributes on the malloc API. It's broken to use more of the allocation.
1
3
It will trigger the -fsanitize=object-size (included in -fsanitize=undefined) and _FORTIFY_SOURCE checks.
Using malloc_object_size is also not efficient. In modern malloc implementations, it usually requires reading out-of-line metadata since they avoid per-allocation metadata.
1
2
Show replies