Bumpalo vec resize behaviour

[earnest vault]

Would anyone knowhow bumpalo's vec type handles resizing?
For example, if I have a bump with [1, 2, 3, 4, 5, 6, 7] and a vec spanning over [1, 2, 3] and the vec needs to expand one more, will it re-allocate then free or free then re-allocate?
In other words, allocate [4, 5, 6, 7] and free [1, 2, 3] (thus creating a hole) or free [1, 2, 3] and then allocate [1, 2, 3, 4]?
(this example ofc ignores the actual resize amount often being 2x)

[flat lynx]

@earnest vault, can you write a code example? The case is not very clear to me from the textual description.

[earnest vault]

For example:

fn test() {
    use bumpalo::collections::Vec;
    let bump = Bump::with_capacity(10);
    let mut vec = Vec::with_capacity_in(3, &bump);
    vec.extend_from_slice(&[0u8; 4]);
}

will vec now take up [1, 2, 3, 4, 5, 6] or [4, 5, 6, 7, 8, 9]

[flat lynx]

Intuitively, just from eyeballing the example - I don't see why any additional allocation must happen there.

1. Bump of size 10 is pre-allocated.
2. Within it you allocated a Vec with size 4.
3. No need for resizing the bump.

[earnest vault]

sorry, 'allocation' probably isn't the right term, I mean within the bump

I'm wondering what region of space in the bump is being taken up by the vec

[flat lynx]

Within the memory already being held by the bump - 4 bytes are going to be overwritten

[flat lynx]

Again - intuitively - the internal pointer of the bump is going to be "bumped" to 4-th byte after all the lines are executed, but the vec is going to point to the first byte in the bump.

[earnest vault]

okay, so it wouldn't be:

1. new buffer is 'allocated' as bump pointer
2. old buffer is given up
   but rather
3. same buffer is kept and just bump pointer is increased

[flat lynx]

Yes, until the pointer exceeds 10, because of with_capacity(10):
https://docs.rs/bumpalo/latest/bumpalo/#what-happens-when-the-memory-chunk-is-full