core.runtime.GC memory alignment

[Manu]

On 29 October 2013 04:33, monarch_dodra <monarchdodra at gmail.com> wrote:

> On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
>
>> I had a lot of informal conversations with Walter trying to get my head
>> around the details here.
>> To my recollection, the intent was that it should behave like C, and that
>> S.alignof must certainly == 128 in that case. It can't work otherwise.
>> Alignment must be inherited by parent structures.
>>
>
> 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.
>
> It doesn't mean that S itself need to be 128 aligned.


Both should be true, if it's not, it's a bug.

 I also recall commenting on that case with ulong. On most architectures it
>> only needs to be 4 byte aligned, but that one is arch specific.
>>
>
> Does it make sense (and should it be illegal) in that case to have
> anything with alignment > 8 ? I just don't see how something like "malloc"
> would be able to deal with them otherwise... ?


Well SIMD vector's require at least 16 byte alignment, so say goodbye to a
major subsection of your CPU ;)
I've never seen a malloc implementation that returns memory that is less
than 16 byte aligned. If you expect higher alignment, typically you use OS
provided AliognedAlloc primitives, or you use tricks like overallocating
and offseting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131029/f6107d19/attachment.html>