Hi. I was accepted as a student to the Google Summer of Code to work on Implemmenting the Immix Garbage Collector in GHC. I'm currently reading the Commentary and the source code in order to understand what needs to be changed. I have some questions which are not central to my work, but I thought I should ask them along with the ones that are, since they may be a source of doubt that would make it harder for me to work in the code.
------------------------------------------------------------------------------- >From http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/BlockAlloc : (...) > Currently, megablocks are never freed back to the OS, except at the end of > the program. This is a potential improvement that could be made. What's the problem with freeing megablocks to the OS? Why isn't it done already? (...) >From Faster laziness using dynamic pointer tagging: (...) > Return adresses have info tables just as heap closures do; this makes stack > frames have almost exactly the same layout as heap closures. The info table > for a return address describes the layout of the stack fram for the garbage > collector, just as the info table for a heap closure describes the layout of > the closure. Is the GC responsible for collecting the Stack objects, or it only scavenges them to find pointers to Heap objects? (...) >From includes/rts/storage/GC.h: (...) > typedef struct generation_ { > unsigned int no; // generation number Why does the generation hold its own number? Can't it be obtained by "this" - generations? (...) > unsigned int n_words; // number of words Is this the total number of words in the all the blocks? Can't it also be obtained by n_blocks * (1 << BLOCK_SHIFT)? (...) > extern generation * g0; > extern generation * oldest_gen; Can't generations[0] and generations[RtsFlags.GcFlags.generations-1] be used? (...) >From rts/sm/GC.c : (...) > nat gens = RtsFlags.GcFlags.generations; I've seen some times this kind of construction in GHC, where a variable is create for an assignment like this, and never changed again. Are these kind of constructions used only for efficiency? (...) >From rts/sm/BlockAlloc.c: (...) > - most allocations are for small blocks The block size is constant, so this should be for a small number of blocks, instead of for small blocks? (...) ------------------------------------------------------------------------------- Ok, these were the questions which are not central to my work. The central question I have now follows. Please correct me if I'm wrong, but it seems to me that the memory allocator goes as follows: _________ ( Program ) --------- ^ | +------------------+ | Object allocator | +------------------+ ^ | +-----------------+ | Block allocator | +-----------------+ ^ | +----------------------+ | Mega block allocator | +----------------------+ ^ | ____ ( OS ) ---- I could find documentation about the Mega block allocator and the Block allocator, but not of the Object allocator. Actually, I made it up myself, since I saw nothing written about it, but I wonder that there should be some code that allocates objects in a block and request a new block when one is needed. I think that the first thing I should do is create a Line allocator, between the Block allocator and the Object allocator. But for this, I need to know where the usual object allocation is done. Another thing: is this the right list to this kind of question? Or should I mail glasgow-haskell-users? Thanks in advance. -- marcot http://wiki.debian.org/MarcoSilva
signature.asc
Description: PGP signature
_______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
