Changes between Version 5 and Version 6 of Commentary/Rts/Storage

Timestamp:

09/12/06 07:58:09 (7 years ago)

Author:

simonmar

Comment:

--

Commentary/Rts/Storage

@@ -42 +42 @@
 [[Image(sm-block.png)]]
 
-We currently have megablocks of 1Mb in size (m = 20) with blocks of 4k in size (k = 12), and these sizes are easy to change  ([[GhcFile(includes/Constants.h)]]).  Block descriptors are currently 32 or 64 bytes depending on the word size (d = 5 or 6).
+We currently have megablocks of 1Mb in size (m = 20) with blocks of 4k in size (k = 12), and these sizes are easy to change  ([[GhcFile(includes/Constants.h)]]).  
 
-So the block allocator has a little more structure:
+Block descriptors are currently 32 or 64 bytes depending on the word size (d = 5 or 6).  The block descriptor itself is 
+the structure `bdescr` defined in [[GhcFile(includes/Block.h)]], and that file also defines the `Bdescr()` macro.
+
+The block allocator has a the following structure:
 
  * At the bottom, talking to the OS, is the megablock allocator ([[GhcFile(rts/MBlock.c)]], [[GhcFile(rts/MBlock.h)]]).
@@ -57 +60 @@
  * Sitting on top of the megablock allocator is the block layer ([[GhcFile(includes/Block.h)]], [[GhcFile(rts/BlockAlloc.c)]]).
    This layer is responsible for providing:
-   * `void *allocGroup(int)`
-   * `void freeGroup(void *)`
-   These functions allocate and deallocate a block ''group'': a contiguous sequence of blocks (the degenerate, and common, case
-   is a single block).  The block allocator is responsible for keeping track of free blocks.  Currently it does this by
-   maintaining an ordered (by address) list of free blocks, with contiguous blocks coallesced.  However this is certanly
-   not optimal, and has been shown to be a bottleneck in certain cases - improving this allocation scheme would be good.
+{{{
+   void *allocGroup(int)
+   void freeGroup(void *)
+}}}
+  These functions allocate and deallocate a block ''group'': a contiguous sequence of blocks (the degenerate, and common, case
+  is a single block).  The block allocator is responsible for keeping track of free blocks.  Currently it does this by
+  maintaining an ordered (by address) list of free blocks, with contiguous blocks coallesced.  However this is certanly
+  not optimal, and has been shown to be a bottleneck in certain cases - improving this allocation scheme would be good.
 
 == The Garbage Collector ==