You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The algorithm description of emballoc 0.1.1 mentions, that the concatenation of free blocks only happens with the following block and not the previous one (cf. step 12). I propose a simple solution, that will prevent such scenarios without the need for the mentioned linear scan.
The key idea is to write the Entry not only to the start of a block (as it is currently done as a header), but also into the block itself. If the block is written to the last four bytes of the memory, the length of the block is known. This in turn would allow to patch the header of that block with the length of the current block to be freed (and the following free block if there is such a block).
It also works with "empty" blocks: from the view of the following block, the previous 4 bytes are a valid header and one needs to jump 0 bytes to the left to access the "real" header (which is the same). This keeps the logic simple and straightforward.
There is no alignment issue, since an allocated block is always rounded up to a multiple of 4, so the entry can safely be written or read.
The text was updated successfully, but these errors were encountered:
The algorithm description of
emballoc
0.1.1 mentions, that the concatenation of free blocks only happens with the following block and not the previous one (cf. step 12). I propose a simple solution, that will prevent such scenarios without the need for the mentioned linear scan.The key idea is to write the
Entry
not only to the start of a block (as it is currently done as a header), but also into the block itself. If the block is written to the last four bytes of the memory, the length of the block is known. This in turn would allow to patch the header of that block with the length of the current block to be freed (and the following free block if there is such a block).It also works with "empty" blocks: from the view of the following block, the previous 4 bytes are a valid header and one needs to jump
0
bytes to the left to access the "real" header (which is the same). This keeps the logic simple and straightforward.There is no alignment issue, since an allocated block is always rounded up to a multiple of
4
, so the entry can safely be written or read.The text was updated successfully, but these errors were encountered: