Cap standard library allocators' maximum supported alignments to target architecture's page size

[mrakh]

Hardware-supported data types have alignment restrictions that are far below the target's page size, and the few people who actually need something beyond page-level alignment (e.g. pointer masking tricks, DMA engine restrictions, huge pages) are better off handling the page mapping themselves anyways.

The benefit of this constraint is that memory allocations via the Allocator interface can be served with at most one system call, the consequences of which are:

• Simplifies implementation
• Gets rid of potential race conditions
• Gives us an OS-enforced upper bound on running time
• Opens up the possibility to implement an async-signal-safe allocator, for use in signal handlers

[SpexGuy]

As someone who often allocates chunks with large alignment, I support this. I think it would be nice to have a platform abstraction over allocating highly aligned chunks, but it doesn't need to be tied to the std.mem.Allocator interface. Having a more specialized api for this use case could have other nice implications as well, like the ability to specify reserve vs commit behavior.

[marler8997]

I think this is a good insight. Some of the allocators would be simplified by this, and I think you may be correct in saying that anyone who cares to have very large alignments likely wouldn't need or be able to use std.mem.Allocator anyway. And nothing prevents libraries from adding their own specialized interfaces for things like this.

The bigger question I would have would be how best to design the API such that these alignment restrictions are properly represented in the type system. For example, alignments are currently using u29, so should we now make this type uXX based in the platform page size? I think it would be nice if we could design it in such a way that alignments larger than the page size would be caught at compile time (through the type system) rather than cause a runtime bug/crash.

[marler8997]

I had another thought. What if instead of restricting alignment to the page size, we restricted it a step further to the maximum required alignment for any type that the target CPU requires (i.e. the maximum value @alignOf can return)? I can't think of any cases that would require alignments larger than this that wouldn't also fall into the same category as those needing alignments larger than the page size.

Limiting the alignment to this might give us better options on how to represent this in the type system.

My current idea is something like this:

// This is the return type of @alignOf
pub const Align = enum {
    _1 = 1,
    _2 = 2,
    _4 = 4,
    _8 = 8,
};
// NOTE: maybe this enum is exposed as a builtin @Align()?

An enum like this would still allow the alignment to be used in mathematical expressions that take an alignment. It would provide a list of all possible alignments that could be switched on by allocators for things like alignment buckets. Having a smaller number of alignments like this would also make it reasonable to have some functions use alignment as a comptime parameter.

P.S. In the cases where larger alignment is needed, a LargeAlignAllocator could be created in the standard library if we think it is a common-enough use case.

[mrakh]

I had another thought. What if instead of restricting alignment to the page size, we restricted it a step further to the maximum required alignment for any type that the target CPU requires (i.e. the maximum value @alignOf can return)? I can't think of any cases that would require alignments larger than this that wouldn't also fall into the same category as those that could need alignments larger the page size.

Page alignment is useful for organizing data to minimize TLB misses. In my opinion, this use case is valid/common/simple enough for allocators to accommodate page alignment, even if there is no CPU instruction that requires it.

The bigger question I would have would be how best to design the API such that these alignment restrictions are properly represented in the type system. For example, alignments are currently using u29, so should we now make this type uXX based in the platform page size? I think it would be nice if we could design it in such a way that alignments larger than the page size would be caught at compile time (through the type system) rather than cause a runtime bug/crash.

I'm a fan of the mantra "make illegal states unrepresentable". The Linux kernel's alloc_pages does this - its order parameter is essentially just a log2 transformation of the actual alignment. We can do the same:

order = 0, alignment = 1
order = 1, alignment = 2
order = 2, alignment = 4
...
order = n, alignment = (1 << n)

Now, as long as we replace the alignment parameter with an order parameter, we can just do assert(order <= log2(page size)) to validate the alignment requirement at compile time.

[fweimer]

I had another thought. What if instead of restricting alignment to the page size, we restricted it a step further to the maximum required alignment for any type that the target CPU requires (i.e. the maximum value @alignOf can return)? I can't think of any cases that would require alignments larger than this that wouldn't also fall into the same category as those needing alignments larger than the page size.

Other reasons for using alignment are:

• Avoiding false sharing within the same cache line, or crossing cache lines in the middle of a data structure.
• Using kernel APIs which have increased requirements for pointer alignment, such as direct I/O.
• Using the lower bits of pointers to store information.
• Masking away pointer bits to obtain a pointer to the start of an allocation from a pointer within the allocation.

[N00byEdge]

I assume this would be the architectures maximum possible page size, not just the minimum one, right? You can have 1G, 2M or 4K mappings on x86 for example, and get a perf improvement for using the larger page sizes