std.allocator needs your help

[Peter Alexander]

On Monday, 23 September 2013 at 21:27:36 UTC, Andrei Alexandrescu 
wrote:
> That allocator would allocate more memory (I suspect there's a 
> gcd calculation somewhere :o)) and then adjust the starting 
> pointer of the allocated block to reach the requested alignment.

That's quite an inefficient use of memory for large alignment 
sizes.

Also, how does it work with your deallocate interface? Suppose I 
request an 0x100 aligned block of 0x100 bytes. Your alignment 
allocator requests 0x200 from the GC, which maybe returns 
[0xffff0040-0xffff0240] and then returns an aligned buffer from 
that [0xffff0100-0xffff0200]. Later, I try to deallocate that 
buffer, which means your alignment allocator has to deallocate 
the original buffer. Where does the alignment allocator store the 
original GC-provided buffer ptr + size? It cannot be determined 
from the buffer I gave it.


> I'd need a handful of good examples where the alignment must be 
> known at runtime. Can you link to some?

mprotect requires a pointer that is a multiple of the system page 
size, which isn't constant.

http://linux.die.net/man/2/mprotect


Reading a file without buffering on Windows requires that you 
align the destination buffer on volume sector size boundaries, 
which is not known at compile time (although many just assume 
4096).

http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx


As I mentioned previously, you may want to also align to the 
cache line size (for performance). This is not known at compile 
time (although again, is often assumed in practice).