3 ms·

Oh? How do you think munmap does it? If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be importan

by geocar 3mo ago

Oh? How do you think munmap does it? If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important. Something I noticed is that _very often_ the code that is calling malloc(n) is keeping track of n somehow for its own reasons (bounds checking, grow/gap pointers, etc) so merging the value halves stack churn and it’s an easy win.

byroot 3mo ago
That's why C23 introduce free_sized [0]. [0] https://en.cppreference.com/c/memory/free_sized https://en.cppreference.com/c/memory/free_sized
- Someone 3mo ago
  >> If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important. > That's why C23 introduce free_sized Is it? C23 still has free, so there’s no guarantee callers wil use free_sized, so the allocator still has to be able to obtain a block’s size from a pointer. Or do I overlook something?
  - inigyou 3mo ago
    I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function
    - Someone 3mo ago
      Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size” call, you can’t have a malloc implementation that doesn’t track block sizes. I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.
      - deleted 3mo ago
        [deleted]
xxs 3mo ago
> keep track of that metadata themselves you obviously don’t need to likely it'd a be perf. hit in most cases. They'd have to copy to the tail end (likely) of the allocated area. Or the start and offset the pointer, they'd need to know the size of the metadata and account for that, including aligning it.Hence, the tail feels 'nicer' It's possible to manually use mmap and forgo malloc entirely, rolling your own arena manager.
simiones 3mo ago
Well, even that doesn't really work, because optimized allocators typicallly don't allocate exactly the amount that you ask for, they allocate some larger chunk to help with both alignment and fragmentation. So, most likely, there are two sizes in reality: the size of your user data that you care about; and the size of the memory chunk in which your user data resides, that free() cares about. So, unless you're willing to go for an API like this, you can't rely on the consumer: int* ptr_to_dest = NULL; size_t size = 10 * sizeof(int); size_t allocated = malloc(&ptr_to_dest, size); if (allocated <= 0 || !ptr_to_dest) { //handle allocation error } //... use ptr_to_dest, size free(ptr_to_dest, allocated); //careful not to pass size here!
inigyou 3mo ago
munmap has metadata in a separate data structure in the kernl

by geocar 3mo ago

byroot 3mo ago

That's why C23 introduce free_sized [0]. [0] https://en.cppreference.com/c/memory/free_sized https://en.cppreference.com/c/memory/free_sized

Someone 3mo ago
>> If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important. > That's why C23 introduce free_sized Is it? C23 still has free, so there’s no guarantee callers wil use free_sized, so the allocator still has to be able to obtain a block’s size from a pointer. Or do I overlook something?
- inigyou 3mo ago
  I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function
  - Someone 3mo ago
    Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size” call, you can’t have a malloc implementation that doesn’t track block sizes. I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.
    - deleted 3mo ago
      [deleted]

xxs 3mo ago

> keep track of that metadata themselves you obviously don’t need to likely it'd a be perf. hit in most cases. They'd have to copy to the tail end (likely) of the allocated area. Or the start and offset the pointer, they'd need to know the size of the metadata and account for that, including aligning it.Hence, the tail feels 'nicer' It's possible to manually use mmap and forgo malloc entirely, rolling your own arena manager.

simiones 3mo ago

Well, even that doesn't really work, because optimized allocators typicallly don't allocate exactly the amount that you ask for, they allocate some larger chunk to help with both alignment and fragmentation. So, most likely, there are two sizes in reality: the size of your user data that you care about; and the size of the memory chunk in which your user data resides, that free() cares about. So, unless you're willing to go for an API like this, you can't rely on the consumer: int* ptr_to_dest = NULL; size_t size = 10 * sizeof(int); size_t allocated = malloc(&ptr_to_dest, size); if (allocated <= 0 || !ptr_to_dest) { //handle allocation error } //... use ptr_to_dest, size free(ptr_to_dest, allocated); //careful not to pass size here!

inigyou 3mo ago

munmap has metadata in a separate data structure in the kernl