New libc malloc patch
bucht at acc.umu.se
Sun Dec 11 19:47:34 PST 2005
Jason Evans wrote:
>> Isn't 8 byte alignment expected by some applications?
> Yes, 8 or 16 byte alignment is expected (in fact I'm of the opinion
> that we should be using 16 byte alignment on i386 due to SSE2/SSE3).
> If I understand your question correctly, you're asking how I get away
> with 4 byte tags. Consider that (assuming 8-byte quantum) a malloc
> (16) call must actually be serviced by at least 24 bytes internally,
> in order to pad to the next quantum size. If I used 8 byte tags,
> then malloc(17) would require 32 bytes internally. By using 4 byte
> tags, malloc(13)..malloc(20) can be serviced by 24 bytes internally.
> At least one implementation (the OS X malloc implementation) uses 2
> byte tags, but this has two problems: 1) unaligned memory access is
> slow on some architectures, and 2) it's too small to handle large
> object sizes, so a different allocation strategy has to be used
> starting at ~12 KB.
Well, I just wondered how you avoided unaligned accesses with a 4 byte tag.
>> How do you know if a allocation is huge if you don't have a tag?
> I know an allocation is huge if its base address is chunk-aligned.
> The actual size is stored in a red-black tree node, which is
> allocated separately.
Ok, expected it was through the address, thanks for answering anyway.
Gonna take some time reading through the code before asking more stupid
More information about the freebsd-current