On Saturday, 1 October 2022 at 01:37:00 UTC, Steven Schveighoffer wrote:
On 9/30/22 11:57 AM, Quirin Schroll wrote:
Also, is the alignment of any type guaranteed to be a power of 2?

In practice, it's not necessarily a power of 2, but it's *at least* 16 bytes.

**Types** always require some power of 2 alignment (on any sensible platform, anyway), and it is usually *less* than 16 bytes - typically `size_t.sizeof`.

The fact that the current GC implementation apparently has a minimum block size of 16 bytes, and that minimum size blocks are always size-aligned, is not guaranteed by the public API and *should not be* when requesting memory for something that the type system says only requires an alignment of `void.alignof == 1`.

D and C both have formal ways to communicate alignment requirements to the allocator; people should use them and not constrain all future D GC development to conform to undocumented details of the current implementation.

In general there are very few types (maybe vectors?) that need alignment more than 16 bytes.

256 bit SIMD (AVX/AVX2) and 512 bit SIMD (AVX512) `__vector`s should be `.sizeof` aligned (32 and 64 bytes, respectively). Memory used for inter-thread communication (such as mutexes) may perform significantly better if cache line aligned (typically 64 bytes, but CPU dependent).

I don't know any other examples off the top of my head.

The list of bit sizes is currently here:

I'm pretty sure those are in **bytes** not **bits**.

https://github.com/dlang/dmd/blob/82870e890f6f0e0dca3e8f0032a7819416319124/druntime/src/core/internal/gc/impl/conservative/gc.d#L1392-L1414

That's not a list of alignments, it is block sizes for some GC memory pools. The alignment of each block depends on the alignment of its pool, not just its size.

It's not immediately obvious from the context, but I suspect the pools are actually page aligned, which would mean that the non power of 2 sized blocks are **not** consistently aligned to their own sizes.

Regardless, it's not part of the public API, so it could change without warning.

Reply via email to