From 6368938b9e5b0ffc4bfd88dc779942c818d55c31 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Mon, 20 Jan 2020 10:08:33 +0100 Subject: [PATCH] Link to `free list` wikipedia article --- .../second-edition/posts/11-allocator-designs/index.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/blog/content/second-edition/posts/11-allocator-designs/index.md b/blog/content/second-edition/posts/11-allocator-designs/index.md index aa216c60..2095fcec 100644 --- a/blog/content/second-edition/posts/11-allocator-designs/index.md +++ b/blog/content/second-edition/posts/11-allocator-designs/index.md @@ -423,7 +423,11 @@ The most common implementation approach is to construct a single linked list in ![](linked-list-allocation.svg) -Each list node contains two fields: The size of the memory region and a pointer to the next unused memory region. With this approach, we only need a pointer to the first unused region (called `head`) to keep track of all unused regions, independent of their number. As you can guess from the name, this is the technique that the `linked_list_allocator` crate uses. +Each list node contains two fields: The size of the memory region and a pointer to the next unused memory region. With this approach, we only need a pointer to the first unused region (called `head`) to keep track of all unused regions, independent of their number. The resulting data structure is often called a [_free list_]. + +[_free list_]: https://en.wikipedia.org/wiki/Free_list + +As you might guess from the name, this is the technique that the `linked_list_allocator` crate uses. ### Implementation