This minor release reduces the memory footprint of the allocator! Thanks @stephan-gh for reporting this issue and testing the fixes!
The problem
Previous versions of this crate immediately initialized the "heap" array with a non-zero value in the first few bytes. This causes the entire array backing the allocator being marked as "initialized with non-zero values" and thus being placed in the .data-section. The .data-section, containing non-zero initialization data, needs to be initialized on device startup. This is done by storing the initialization data in the flash and copying them to the RAM in startup. While this is fine in general, this poses a problem in this crate:
If a user creates an 8kiB allocation heap, the first 4 bytes are actually initialized, but the whole 8kiB get added to the Flash size. This might be problematic in constrained environments.
Therefore the allocator will now lazily initialize the heap memory on the first allocation. The heap array remains uninitialized, except for the first few bytes, which are zeroed out. This solves the aforementioned problem.
Note, that this feature is on by default and not user-controllable. There should not be any noticeable performance differences (after all, it is only one additional if when allocating).
Update procedure
To update the crate, simply run (if you already depend on it):
$ cargo update -p emballocIf you want to use this as a new dependency in your Rust project, just add the following snippet to your Cargo.toml
[dependencies]
emballoc = "0.3.0"and register the emballoc::Allocator as the global allocator:
#[global_allocator]
static ALLOCATOR: emballoc::Allocator<4096> = emballoc::Allocator::new();