Alignment of first element in managed byte array

[tmds]

What's the alignment of the first element in a managed byte array?

Is it guaranteed to match the machine word size, for example: 8 bytes aligned on x64, and 4 bytes on aligned on x86?

I don't find it in https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md. So maybe no alignment may be assumed?

cc @VSadov @EgorBo @stephentoub

[EgorBo]

Arrays are GC objects, so they're pointer-aligned (e.g. 8 bytes on 64bit). Array's data is located at sizeof(void*) + 4 bytes + 4 bytes in CLR,
so the answer is: yes, first item in arrays is always pointer-aligned in CLR (might not be true in other implementations).
The only exception are arrays of double (and long?) on 32bit which get special treatment to promise 8 byte alignment on 32 bit platforms.

I don't find it in https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md.

I don't think object layout should be mentioned there anyhow. E.g. String doesn't promise pointer alignment for chars.

[tmds]

I don't think object layout should be mentioned there anyhow.

If the alignment is expected to be guaranteed by all runtime implementation, then it could be mentioned.

If it isn't guaranteed, then it shouldn't be mentioned and "portable" code should not rely on it.

[EgorBo]

If you see short[] you can rely on its data to be always naturally aligned (so, 2-byte alignment). 8-byte alignment for the first item is just a CLR's implementation detail (other runtimes are free to provide different guarantees). So I don't think MemoryModel needs any amendments

When managed by the .NET runtime, variables of built-in primitive types are properly aligned according to the data type size

is enough here

[tmds]

For some context: I have data in a byte[]. The data is different values in big endian and all the data is stored aligned. From an offset I want to read data in an int[].

I was wondering if I could do MemoryMarshal.Cast<byte, int> on the Span<byte> (and then BinaryPrimitives.ReverseEndianness).

The Cast would be ok due to the GC alignment.

To not rely on the GC alignment, I can Span<byte>.CopyTo the int[], and then call ReverseEndianness on that array.

[VSadov]

Another way to look at this - The Memory Model only guarantees that byte array elements are naturally-aligned (i.e. byte-aligned). It just happens from the GC implementation that all objects are aligned at least on the native word size. Then it so happens that array header size is a multiple of 64bit words (that is the case even on 32bit and that is how double[] can have naturally aligned elements on 32bit - GC ensures 64bit alignment of double-containing array objects, and then elements are also aligned).

In theory it would be ok for byte/int arrays to have smaller headers and save a few bytes, but that could add awkward special casing in indexing. Basically - it is an implementation detail, but also one that is unlikely to change in the near future.
Other runtimes could do something different. I can't tell right away if Mono guarantees the same. (most likely)