[deleted]
Why malloc always does more than I asked for?
31–40 of 52 posts
Re: Why malloc always does more than I asked for?
#32[deleted]
Re: Why malloc always does more than I asked for?
#33> so alloc() doesn’t just need to hand back a pointer. it needs to hand back a pointer that’s correctly aligned for whatever type the caller is about to store there. Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void ). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE val…
Isn't 64 bytes needed for AVX512, then?
Re: Why malloc always does more than I asked for?
#34Old magazines like The C/C++ Users' Journal and DDJ used to have ads for companies selling malloc()/free() replacement libraries, exactly because a single implementation isn't adequate to all scenarios.
These still exist, like dlmalloc, jemalloc, tmalloc (which has new features). Built-in malloc is good enough for almost everything if you don't have excessive time on your hands, but thinking deeper about memory allocation is one of those things that can make your software higher quality if you have time for it—just like utilising SIMD (also on today's front page) or careful use of caching.
Re: Why malloc always does more than I asked for?
#35I've read some allocator walkthroughs before but I thought that this line stood out: "to get individual free() working, the allocator needs to remember something about every allocation it handed out. and that’s the moment metadata stops being optional." That's just a very nice distillation of an important concept.
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.
munmap has metadata in a separate data structure in the kernl
Re: Why malloc always does more than I asked for?
#36Earlier quoted context omitted.
That's why C23 introduce free_sized [0]. [0] https://en.cppreference.com/c/memory/free_sized
>> 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?
I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function
Re: Why malloc always does more than I asked for?
#37Earlier quoted context omitted.
In the other words, free() is a flawed API. :-)
Actually yes, the malloc/free API (inherited from the ALLOCATE and FREE statements of PL/I) is too simple. The metadata that malloc always attaches to the allocated memory would normally be useful for the user (i.e. having access to values like the currently allocated size and the total size of the allocation). Very frequently, the user must duplicate inside the allocated memory the same information that already exis…
Efficient and generalized are opposing forces. Malloc is fine for what it is but you can do better by specialising.
Re: Why malloc always does more than I asked for?
#38> so alloc() doesn’t just need to hand back a pointer. it needs to hand back a pointer that’s correctly aligned for whatever type the caller is about to store there. Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void ). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE val…
> So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86
Fun story. Back in the early 2000s, my Delphi OpenGL program randomly crashed when I tried to use vertex buffers. I spent a lot of time checking this and that, before I realized it might be an alignment issue.
Sure enough, Delphi memory allocator at the time only provided 4-byte alignment, while NVIDIA's drivers used aligned SSE instructions which require 16-byte alignment.
So, had to manually align the buffers before passing them to OpenGL.
Re: Why malloc always does more than I asked for?
#39> so alloc() doesn’t just need to hand back a pointer. it needs to hand back a pointer that’s correctly aligned for whatever type the caller is about to store there. Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void ). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE val…
Isn't 64 bytes needed for AVX512, then?
There are two types of load/store instructions, one type requires alignment (vmovdqa), the other can load unaligned data (vmovdqu), in the case of AVX-512 the required alignment is 64 bytes. I assume aligned loads and stores are faster/have lower latency. For SSE/AVX you can look up the alignment requirements in Intel's intrinsics guide [0].
[0] https://www.intel.com/content/www/us/en/docs/intrinsics-guid...
Re: Why malloc always does more than I asked for?
#40Earlier quoted context omitted.
>> 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?
I suppose by default it will just call free, but you can substitute different malloc implementations, maybe one with a malloc_no_header function
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.