3 ms·
I missed what the free_sized() is good for. From a naive look it seems redundant. Still no computed goto? Some progress on standardizing inline assembler synt
by nn3 5y ago
I missed what the free_sized() is good for. From a naive look it seems redundant.
Still no computed goto?
Some progress on standardizing inline assembler syntax would be nice too.
Or maybe it won't matter anymore because everyone will be using either gcc or clang.
- pkhuong 5y agosized free is good for safety if your malloc cross-checks the size argument with its metadata, and for performance if your malloc assumes the size argument is correct without having to hit malloc's internal metadata. There's also a middle ground where you get more ILP by assuming the size argument is correct (for performance), and overlap the work of `free`ing memory with a confirmation that the size argument matches malloc's internal metadata.
- aseipp 5y agoModern allocators divide allocations into "size classes" based on the size of the allocation (normally rounded up to some power of 2 or whatever.) When you call something like free(m), the allocator will often have to figure out what size class 'm' was put into before it can proceed. For example, once you free some memory you might not return it to the OS, but keep it around in a cache structure so that it can be re-used. You can only put 'm' into the right cache if you compute the size class and use that. If the metadata for the object is "out of band" (i.e. not next to it directly), figuring out the size class of 'm' might be a little costly. If your allocator can't use the sizing information when free'ing, it can just be a no-op. If it can, it can result in some performance gains. You also get the bonus the allocator can run stricter consistency checks on the object itself i.e. free(m,size) can ensure that 'm' actually is of the given 'size', or abort the program. This can help find and catch latent bugs.