std.allocator needs your help

[Andrei Alexandrescu]

On 9/23/13 3:12 PM, Peter Alexander wrote:
> 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.

I don't see a way around it unless the allocator natively provides a 
large alignment size, which it would then advertise in its "alignment" 
constant. The problem is independent of this particular design.

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

Walter noted the same issue. I'd need to think about it. A simple 
solution is to simply store the size just before the pointer returned, 
in a dope block manner.

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

Thanks! I see posix_memalign is a corresponding call that returns a 
page-aligned chunk of memory. I assume calls like mmap also return 
page-aligned chunks. Indeed it is a problem for the current design that 
the alignment must be known during compilation.

> 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

I see there's a difference between x86 and Itanium in page size...

I'm trying to lean toward handling these as rare/exotic cases without 
outright eliminating them, while providing simple and efficient handling 
of alignment for the frequent cases (i.e. allocate ints at addresses 
multiple of 4 etc).

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

Indeed.


Andrei