Remove a branch from `try_alloc_layout`? about bumpalo

[overlookmotel]

Come to think of it, if we've allocated 4 GiB originally and the max size of the bump is 4 GiB, then the bump can only ever require 1 chunk, and further branches can be removed.

Can this be right???

[fitzgen]

When Bump allocates a chunk from global allocator, request a chunk of 4 GiB size. If my understanding is correct, this will only consume 4 GiB of virtual memory, not physical memory (though I may be wrong about that, in which case my whole theory here collapses!)

Two things:

1. This is correct if the code is running on a system with virtual memory. That isn't guaranteed and bumpalo doesn't require that. Notably, Wasm doesn't have virtual memory.

2. This would put us in the position of needing to (or at least being pressured to) manage virtual memory and detect when we can madvise away pages that we made physical mappings for because we touched them earlier, but then we did a reset.

Do you think this would work? And if so, would it be a worthwhile optimization?

I think this kind of thing is very valid for a bump allocation library to do, but it is also making a trade off to be more focused on a particular environment and use case and less general purpose. For that reason I don't think it is the right choice for this library.

[fitzgen]

But yeah, once you accept virtual memory, you don't even need to explicitly check against the end of the bump region. You just have a guard page just after (before, when bumping downwards) the end of the bump region and then check that sizeof(T) < sizeof(page) which should be constant propagated away 99.99% of the time. Then you have a branch-free allocation path and when you run out of capacity you attempt to write to the guard page and then that raises a signal and you catch that and return allocation failure.