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

Add image alt text

Browse Source
This commit is contained in:
Philipp Oppermann
2019-06-21 12:08:39 +02:00
parent 518f5247c5
commit 2d16cce255
1 changed files with 11 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
blog/content/second-edition/posts/10-heap-allocation/index.md
View File

@@ -680,7 +680,17 @@ fn kernel_main(boot_info: &'static BootInfo) -> ! {
When we run it now, we see the following: When we run it now, we see the following:
![](qemu-bump-allocator.png) ![QEMU printing `
heap_value at 0x444444440000
vec at 0x4444444408000
Some Rust operating systems and their websites:
{
"Fuchsia (partly)": "https://fuchsia.googlesource.com/fuchsia/",
"RedoxOS": "https://redox-os.org/",
"Tock Embedded Operating System", "https://www.tockos.org/",
}
panicked at 'allocation error: Layout { size_: 4, align_: 4 }', src/lib.rs:91:5
](qemu-bump-allocator.png)
As expected, we see that the `Box` and `Vec` values live on the heap, as indicated by the pointer starting with `0x_4444_4444`. The reason that the vector starts at offset `0x800` is not that the boxed value is `0x800` bytes large, but the [reallocations] that occur when the vector needs to increase its capacity. For example, when the vectors capacity is 32 and we try to add the next element, the vector allocates a new backing array with capacity 64 behind the scenes and copies all elements over. Then it frees the old allocation, which in our case is equivalent to leaking it since our bump allocator doesn't reuse freed memory. As expected, we see that the `Box` and `Vec` values live on the heap, as indicated by the pointer starting with `0x_4444_4444`. The reason that the vector starts at offset `0x800` is not that the boxed value is `0x800` bytes large, but the [reallocations] that occur when the vector needs to increase its capacity. For example, when the vectors capacity is 32 and we try to add the next element, the vector allocates a new backing array with capacity 64 behind the scenes and copies all elements over. Then it frees the old allocation, which in our case is equivalent to leaking it since our bump allocator doesn't reuse freed memory.