Comments (4)
Thanks for filing an issue.
That example is setting the allocation limit after allocating a chunk. But the allocated chunk could have been with a little more capacity than requested for a variety of reasons, so you might already have more capacity than the limit by the time you set the limit. Note that the set_allocation_limit
docs have this tidbit:
The allocation limit is only enforced when allocating new backing chunks for a Bump. Updating the allocation limit will not affect existing allocations or any future allocations within the Bump's current chunk.
So if you set the limit and then allocate, you should run into the limit and start getting allocation failures.
from bumpalo.
Not really after you've already allocated, because if there isn't enough capacity in the current chunk to satisfy the reservation request, we can't resize the current chunk that the Bump
is currently parceling out. We would have to allocate a new chunk for the remaining capacity that is left over after accounting for the capacity in this chunk, but bumpalo's architecture doesn't allow for "future chunks" that are pre-allocated before we are done with the current chunk. And also, it isn't clear whether that capacity needs to be contiguous for one big allocation (eg a single big slice) or can be non-contiguous for a bunch of small allocations (eg a hundred usize
allocations).
If you wanted to pre-allocate space for one big chunk, you could do something like bump.dealloc(bump.alloc_layout(Layout::new(capacity, 1)))
. But note that, if the current chunk doesn't have capacity for that layout, this will allocate a new chunk that does have capacity for that layout, and then even after the dealloc
the Bump
will allocate out of that new chunk. This means that any leftover capacity in the original chunk is effectively leaked until the bump is reset or dropped. Here is a concrete example:
- create a new bump
- starts with zero capacity
- allocate a
u16
- bump doesn't have enough capacity for the
u16
- so it allocates a new chunk with (say) 512 bytes of capacity
- the
u16
is allocated within that chunk - there is 510 bytes of capacity remaining
- bump doesn't have enough capacity for the
- do the
bump.dealloc(bump.alloc_layout(Layout::new(512, 1))
thing to reserve 512 bytes of capacity- current chunks capacity of 510 is not large enough to satisfy request for 512 bytes
- new chunk is allocated that can fit 512 bytes
- old chunk's 510 bytes of previously available capacity will now "leak" and not be used for any bump allocations until the
bump
is dropped orbump.reset()
is called
FWIW, you can check the remaining capacity in the chunk via bump.chunk_capacity()
and determine whether it is worth it to do the reservation trick or not, based on how much capacity would be "leaked".
But yeah, to sum up: there isn't a simple general solution here, the way there is for Vec
, and so I don't think it makes sense to add a bump.reserve(capacity)
method because there are too many subtleties and potential trade offs involved.
from bumpalo.
Ah, thanks! :)
Is there anyway I can reserve capacity after initialization? (Similar to Vec::reserve
) Since I need to set the limit before reserving capacity. I couldn't find a similar API
from bumpalo.
To be clear, my usage in specific is using Bump
is fixed to a specific amount of memory, hence the original snippet :)
But I understand your point, thanks! (I might try out dealloc(alloc(...))
).
from bumpalo.
Related Issues (20)
- May panic due to unwrap on Err HOT 2
- Missing Clone for Box HOT 2
- Add rust-version to Cargo.toml HOT 1
- Request to yank bumpalo v3.12.1 HOT 1
- Implement `std::io::Write` for `Vec<'bump, u8>` HOT 1
- Add a `bumpalo::collections::ThinSlice` type HOT 1
- Memory leak may happen after calling `Bump::dealloc`. HOT 2
- `Box::pin_in` violates pin's drop guarantee HOT 1
- `allocator_api` tests failing HOT 2
- Remove a branch from `try_alloc_layout`? HOT 3
- Improve performance of `extend_from_slice` where `T: Copy` HOT 4
- Ability to create Bump from pre-existing memory allocation? HOT 9
- MSRV disagrees between Cargo.toml and CHANGELOG.md HOT 2
- Minimum alignment HOT 3
- Analysis of Bump Allocator Performance HOT 1
- Execution of test cases at a particular compilation optimization level appears to be stack overflow
- Miri error with `allocator_api` and `Box`-pointer roundtrips
- Please consider relaxing the MSRV of this crate HOT 1
- `alloc` should require `T: !Drop` or be `unsafe` HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bumpalo.