if (new_size_aligned < buf_aligned_len) {
const ptr = buf_unaligned.ptr + new_size_aligned;
// TODO: if the next_mmap_addr_hint is within the unmapped range, update it
os.munmap(@alignCast(ptr[0 .. buf_aligned_len - new_size_aligned]));
return true;
}
// TODO: call mremap
// TODO: if the next_mmap_addr_hint is within the remapped range, update it
return false;
Does it mean that resizing up is impossible now with PageAllocator? Shouldn’t there be an issue for that?
Might be worth noting these parts of the doc comment for resize:
/// Attempt to expand or shrink memory in place. [...]
///
/// A result of `true` indicates the resize was successful and the
/// allocation now has the same address but a size of `new_len`. `false`
/// indicates the resize could not be completed without moving the
/// allocation to a different address.
If you’re just looking to increase the size of the allocation, realloc might be what you’re looking for instead. If you think the resize implementation could guarantee the re-map without moving the address in your test case, then it’d be worth filing an issue for sure.
Might be worth noting these parts of the doc comment for resize:
Yes I saw that but as:
mremap seems to be able to fail if resize is impossible (from the man page: By default, if there is not sufficient space to expand a mapping at its current location, then mremap() fails)
mremap is suggested in the comment
I though that this requirement was “enforceable” with mremap. I might try to push a PR although I don’t know what would be the requirement for it to be accepted…
If you’re just looking to increase the size of the allocation, realloc might be what you’re looking for instead.
This is where it gets a little fuzzy for me because realloc don’t seem to be part of the Vtable interface to Allocator so PageAllocator could not provide that function. Yet realloc is part of the public interface of the Allocator struct. For example, there are a couple of realloc test in general_purpose_allocator.zig but no implementation, so I assumed it is testing the function in Allocator.zig.
Not quite sure what you mean by this. std.heap.page_allocator is a (slightly special) Allocator instance, so it has access to the std.mem.Allocator functions.
I think what may be confusing here is the fact that the entire file in the Allocator.zig is actually being used like a struct - the virtual table is only a part of it. So because of that, it may look like the table itself is the only object in that file, but the whole file is the actual object though.