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

Replying to

and

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

Replying to

and

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.

1

2

Replying to

and

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

Replying to

and

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

Replying to

and

Extended malloc/realloc APIs providing the size as an output parameter is more efficient but it's still not ideal and runs into the same alloc_size issue. The best way to do it is really just having the collection types be aware of the malloc size classes to choose good sizes.

1

Replying to

and

Makes sense. I deal in small allocations so much I forgot about large ones 😂 thanks for the info! (And yeah, I’ve been looking into tuning collection growth strategies specifically to avoid the overhead of asking for the size. It’s particularly steep for us for silly reasons)

1

2

Replying to

and

Bake the size into the address of each object 😅

1

Replying to

and

NanoMalloc on Darwin does that!

1

2

Replying to

and

github.com/GrapheneOS/har uses completely out-of-line metadata and knows the size of slab allocations solely based on their address. It isn't a performance-oriented allocator though. Has design decisions and tricks which could be used in a performance-oriented design though.

GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has...

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

5:01 AM · Nov 13, 2021Twitter Web App

Replying to

Well

doesn’t have to look nearly as far. Zalloc (XNU’s allocator) has (for half a release already): - 100% out of line metadata - va sequestering (isolation) - dynamically scaling cpu caching (driven by contention) - zero on free (checked on alloc)

2

6

Replying to

C supports va_list which is a huge vulnerability for allocators because it's just out there, listing the va... 🤨

2

2

Show replies