Re: New libc malloc patch

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 
questions. =)

/Johan Bucht