In regards to std.heap.page_size_min, page_size_max, and pageSize(), from #31609 (comment):
I had a chat with @mlugg about this. We agreed that 256 is okay as a value here. However, we also agreed that, both as a result of this change and how these constants are already used in practice, "page size" is a poor name for them, and the doc comments also aren't great.
My contention is basically that pages have to do with virtual memory, and the value being introduced here has nothing to do with pages because there's no MMU. Matthew pointed out that what we really care about at the end of the day is the system's granularity of mmap (or the OS's equivalent allocation function) regardless of whether that function actually works with pages in the hardware sense. We really only use the term "page size" because we've inherited it from the POSIX era of systems, but there's no hard rule saying that the granularity of mmap (or the OS equivalent) should have any connection to the page size that the underlying MMU is configured for; an OS could present the illusion of 8k "pages" on a 4k MMU, for example.
Matthew suggested mmap_align_min/mmap_align_max/mmapAlign(), and for the constants to be typed as std.mem.Alignment to encode the power-of-two requirement (and the fact that they really are alignment values).
In regards to `std.heap.page_size_min`, `page_size_max`, and `pageSize()`, from https://codeberg.org/ziglang/zig/pulls/31609#issuecomment-12055419:
> I had a chat with @mlugg about this. We agreed that 256 is okay as a value here. However, we also agreed that, both as a result of this change and how these constants are already used in practice, "page size" is a poor name for them, and the doc comments also aren't great.
>
> My contention is basically that pages have to do with virtual memory, and the value being introduced here has nothing to do with pages because there's no MMU. Matthew pointed out that what we really care about at the end of the day is the system's granularity of `mmap` (or the OS's equivalent allocation function) regardless of whether that function actually works with pages in the hardware sense. We really only use the term "page size" because we've inherited it from the POSIX era of systems, but there's no hard rule saying that the granularity of `mmap` (or the OS equivalent) should have any connection to the page size that the underlying MMU is configured for; an OS could present the illusion of 8k "pages" on a 4k MMU, for example.
>
> Matthew suggested `mmap_align_min`/`mmap_align_max`/`mmapAlign()`, and for the constants to be typed as `std.mem.Alignment` to encode the power-of-two requirement (and the fact that they really *are* alignment values).