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

Remove old content

Browse Source
This commit is contained in:
Philipp Oppermann
2020-01-14 11:49:07 +01:00
parent c92b0d46dc
commit 64e5b67f35
1 changed files with 0 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -833,28 +833,10 @@ Most notably, no traversal of the list is required for deallocation either. This
## What's next?
---
# Old
## Performance
The linked list based approach has some performance problems. Each allocation or deallocation might need to scan the complete list of holes in the worst case. However, I think it's good enough for now, since our heap will stay relatively small for the near future. When our allocator becomes a performance problem eventually, we can just replace it with a faster alternative.
## Summary
Now we're able to use heap storage in our kernel without leaking memory. This allows us to effectively process dynamic data such as user supplied strings in the future. We can also use `Rc` and `Arc` to create types with shared ownership. And we have access to various data structures such as `Vec` or `Linked List`, which will make our lives much easier. We even have some well tested and optimized [binary heap] and [B-tree] implementations!
[binary heap]:https://en.wikipedia.org/wiki/Binary_heap
[B-tree]: https://en.wikipedia.org/wiki/B-tree
---
TODO: update date