@@ -20,7 +20,13 @@ work_request_link = "https://airtable.com/shr4qt9t9kz7RaOIa?prefill_Grant+ID=A01
2020
2121# Loom Pointer Compression Apprenticeship
2222
23−This project makes it possible to at least double the maximum addressable loom space. Use of an unused bit in loom offset references, which are currently 29 bits, can increase the addressable loom space from 2GB to 4GB, and aligning all allocations on an 8-byte boundary can further double the addressable loom space from 4GB to 8GB.
23+This project makes it possible to at least double the maximum addressable loom space, which is constrained by the number of bits in a loom offset (`u3_post`).
24+
25+U3 uses 32-bit noun references, and 2 of those bits are used for type tags (in the case of indirect references to loom allocations). The remaining bits are availabe for use as word-aligned (4-byte) offsets/indexes into the memory of the loom, and all allocations are sized and aligned in terms of words.
26+
27+Increasing the alignment boundaries of loom allocations to some larger power-of-two (call it `X`) lets us effectively use additional bits (`log2(X)` to be precise) in our loom offsets -- since those bits will always be zero, we can shift them off and don't need to store them inside our 32-bit references. Each additional bit doubles the size of the addressable space; in this way, we can grow the loom without switching from 32-bit to 64-bit references (which should also be done, but is a larger project subject to other constraints). This "pointer compression" trick is used to great effect by the JVM.
28+
29+Switching to 8-byte (2-word) alignment buys us one additional bit, and since our minimum allocation (the size of a cell) is 6 words, it does so without imposing costly padding. Higher levels of alignment should be considered, but may not be worthwhile outside of specialized use-cases, as they will involve padding of all cell allocations (barring more dramatic changes to the memory layout of nouns).
2430
2531## Deliverables
2632