core.runtime.GC memory alignment

[David Nadlinger]

On Monday, 28 October 2013 at 18:33:49 UTC, monarch_dodra wrote:
> But is that really what it means though? From the above 
> conversation, it would instead appear to mean that:
> struct S
> {
>     int i;
>     align(128) int j;
> }
> in this case, the *padding* needed until we reach j is 128 
> bytes.

Like Manu, I think the only sane way for align() to behave is 
like GCC's/Clang's "aligned" attribute, which would both add 
padding such that j is at offset 128, and ensure that any 
variables of type S are aligned to 128 bytes as well.

> I just don't see how something like "malloc" would be able to 
> deal with them otherwise... ?

Raw system malloc(), without knowing anything about the type, 
obviously cannot honor any special alignment requests. Thus, 
usually special primitives exist which accept an additional 
parameter to specify the target alignment (cf. the std.allocator 
discussion). If you really want to use C malloc() for your 
256-byte-aligned objects, you have to handle things yourself, 
e.g. by over-allocating and then adjusting the base pointer or 
similar strategies.

David