Fixed range relying on lazy commit?

For limiting some subsystems to a maximum allocation-size, I was experimenting with the fixed range configuration as it seemed particularly suited for my use-case.
I ran into some problems during initialization though, as it seems to be accessing a memory range that has not been committed yet.

Looking at the tests for it, it seems that it relies on everything being committed beforehand.

From the test:

auto size = bits::one_at_bit(28);
auto oe_base = DefaultPal::reserve(size);
DefaultPal::notify_using(oe_base, size); // <--- Commiting the entire range
auto oe_end = pointer_offset(oe_base, size);
std::cout << "Allocated region " << oe_base << " - " << pointer_offset(oe_base, size) << std::endl;

CustomGlobals::init(nullptr, oe_base, size);

I'm trying to run this on a platform that does not have lazy commit, so running a notify_using on the entire range would fully commit all pages to the range, which is undesirable.

Main questions:

• Is this behavior (i.e. the need for the range to be committed beforehand) intentional and desired?
• Is there currently a supported way around this so that the allocator will actively call 'notify_using' on the bits that it uses for the pagemap?

I've only just starting looking into snmalloc and I'm impressed by the clean code and high level of configurability, so I am kind of hoping this can be setup in the Config without having to change the backend too much :)

Start with the fixed-range tests and the initialization path using CustomGlobals::init, DefaultPal::reserve, and DefaultPal::notify_using. Trace how the pagemap accesses the supplied range and determine whether initialization can avoid committing the entire range. Done means the intended behavior is documented and covered by a test for platforms without lazy commit.