michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-16 22:37:49 +00:00
Code Issues Projects Releases Wiki Activity

One _million_ boxes suffice

Browse Source
This commit is contained in:
Philipp Oppermann
2019-06-25 19:25:08 +02:00
parent 5f1d6aed2e
commit 55b96f21b6
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
blog/content/second-edition/posts/11-allocator-designs/index.md
View File

@@ -201,8 +201,8 @@ fn kernel_main(boot_info: &'static BootInfo) -> ! {
} }
println!("vec at {:p}", vec.as_slice()); println!("vec at {:p}", vec.as_slice());
// try to create one billion boxes // try to create one million boxes
for _ in 0..1_000_000_000 { for _ in 0..1_000_000 {
let _ = Box::new(1); let _ = Box::new(1);
} }
@@ -243,7 +243,7 @@ As expected, we see that the `Box` and `Vec` values live on the heap, as indicat
[reallocations]: https://doc.rust-lang.org/alloc/vec/struct.Vec.html#capacity-and-reallocation [reallocations]: https://doc.rust-lang.org/alloc/vec/struct.Vec.html#capacity-and-reallocation
While the basic `Box` and `Vec` examples work as expected, our loop that tries to create one billion boxes causes a panic. The reason is that the bump allocator never reuses freed memory, so that for each created `Box` a few bytes are leaked. This makes the bump allocator unsuitable for many applications in practice, apart from some very specific use cases. While the basic `Box` and `Vec` examples work as expected, our loop that tries to create one million boxes causes a panic. The reason is that the bump allocator never reuses freed memory, so that for each created `Box` a few bytes are leaked. This makes the bump allocator unsuitable for many applications in practice, apart from some very specific use cases.
### When to use a Bump Allocator ### When to use a Bump Allocator