Does this mean that malloc() is fine for AVX2 (32 byte alignment) nowadays?
"Any memory that's allocated dynamically via new or malloc is guaranteed to be properly aligned for objects of any type, but buffers that are not allocated dynamically have no such guarantee"
Conversation
Replying to
I believe the only requirement is that the memory is aligned as per system requirements. So if your 32-bit HW can't BUS split on 1-3 byte aligned addresses, the result must be 4 byte aligned. Only way you can be sure is aligned_alloc.
1
A problem with malloc/aligned_alloc is that compatibility with free() often requires the size to be stored at the head of the allocation. VirtualAlloc/mmap require the owner to track the size. You get the whole allocation, no funky secret header.
2
Most modern malloc implementations avoid having metadata headers on allocations but rather use slab allocation with slabs containing the same size of allocation and they find the slab metadata based on tricks like alignment, such as using 64k aligned regions for everything.
1
1
Slab allocations are naturally aligned to the size class stored in the slab up to the region alignment size used by the allocator. For example a slab allocator naturally has 64 byte alignment for 64 byte allocations because it will have a 4k / 16k aligned region with only those.
It continues all the way up until you reach the alignment they use for slabs. 1024 byte allocations with a slab allocator will naturally be 1024 byte aligned, etc.
Typical to align slabs to page size (usually 4k or 16k) so the natural allocation alignment peaks at the page size.
1
1
Mappings created with mmap are tracked in the kernel. Linux allocates VMA structs for each one, although it tries to merge adjacent VMAs. There's still metadata, especially if you're using the API to achieve larger than page size alignment with padding + unmapping head/tail.
1
1
Show replies