summaryrefslogtreecommitdiff
path: root/notes
diff options
context:
space:
mode:
Diffstat (limited to 'notes')
-rw-r--r--notes/260822-release3.md68
1 files changed, 66 insertions, 2 deletions
diff --git a/notes/260822-release3.md b/notes/260822-release3.md
index fa47ab5..e569ed9 100644
--- a/notes/260822-release3.md
+++ b/notes/260822-release3.md
@@ -227,12 +227,76 @@ the following schema in practice:
* That means we have a maximum trie height of 6, with 2 spare bits.
+For larger size classes, the meaningful bit-count goes down one by
+one, while the bit-count of words increases one by one:
+
+* 256-byte slots: 27 bits / 6-bit words: max height 5
+
+* 512-byte slots: 26 bits / 7-bit words: max height 4
+
+* 1 KiB slots: 25 bits / 8-bit words: max height 4 (ugh!)
+
+* 2 KiB slots: 24 bits / 9-bit words: max height 3
+
The need to move entire node contents to keep the trie sorted worries
me a little, but I think it should be fine. Just make sure to sort
the indexes within each free-list chunk in-place before iterating
through them to insert them into the trie.
-I'm not going to implement this yet. It's way too much complexity,
-only to offer a feature that may hardly ever be needed.
+
+### How to traverse
+
+Now that we have a sorted trie of pointers, it's relatively easy to
+traverse it to find contiguous sequences.
+
+Remember that we shifted our pointer values down, to erase bits which
+are always zero. This means every array position within every node
+needs to be checked for an interruption, except in the deepest level
+where you have to be careful not to produce a false positive, since,
+for example, splitting 28 bits into 5-bit words means the last level
+can only ever have 8 array positions occupied (from the last 3 bits)
+rather than the full 32.
+
+So, we do the following loop:
+
+1. Take the lowest pointer (index) in the trie, which is the first
+ non-NULL at the highest level. It's the start of a memory span.
+ Begin a depth-first search.
+
+2. Continue the search until you hit an interruption. You found the
+ end of the current span.
+
+3. If the span is long enough, turn it into a vacancy-list entry;
+ otherwise turn it into free-list chunks.
+
+4. Continue the search to find the next non-NULL pointer; it's the
+ start of the next span. Go to step 2.
+
+
+### Will I add it to Meta Alloc?
+
+No, I'm not going to implement this yet. I think it's way too much
+complexity for a feature that may hardly ever be needed.
But it was fun to come up with, and good to know that it's possible.
+
+
+### Useful to others?
+
+Can any general-purpose allocator using free-lists make use of this
+strategy?
+
+Yes, provided that:
+
+* Each free-list entry points to a memory slot that can hold at least
+ two references to other slots, but preferably many more.
+
+ Only two pointers per level would mean you have to split pointers
+ into individual bits to navigate. Given 48-bit pointers, that'd
+ mean a maximum trie height of 48.
+
+* The slots are of a known equal size, or have enough extra room to
+ also store a size header I guess?
+
+ I've not thought much about unequal slot size, since it isn't
+ relevant to Meta Alloc, but I think it would work.