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