[freesci-develop] cvs: jameson

[FreeSCI CVS repository]

CVSROOT:        /var/cvs/freesci
Module name:    freesci
Changes by:     jameson 2005/10/18 06:01:36 GMT

Modified files:
        .              : Tag: glutton ChangeLog 
        src/engine     : Tag: glutton Makefile.am game.c kernel.c 
                         klists.c kscripts.c scriptdebug.c seg_manager.c 
                         vm.c 
        src/include    : Tag: glutton Makefile.am engine.h hashmap.h 
                         seg_manager.h vm.h 
        src/scicore    : Tag: glutton Makefile.am hashmap.c 
Added files:
        src/engine     : Tag: glutton gc.c 
        src/include    : Tag: glutton gc.h reg_t_hashmap.h 
        src/scicore    : Tag: glutton reg_t_hashmap.c 

Log message:
* Added a mark & sweep garbage collector

The collector conservatively considers all scripts and objects on the
heap to contribute to the root set, except for scripts whose "locker" count
is at zero. The collector traverses all heap objects, but only deallocates
* lists
* list nodes
* clones
at the moment. Consequently, explicit deallocation for those entities has
been disabled, fixing (for me) the Jones256 intro speed check (even if the
first gc occurs afterwards, i.e. I'm not passing just because of gc
slowdown).

GC is performed every 32768 kernel calls (since our clone, node, list
etc. tables currently hold at most 65536 entries, this seemed like a safe
number-- I did encounter overflows in Jones256 before automating gc calls).

The 32768 number can be adjusted in the debugger by setting variable
gc-interval ("set gc-interval 1" etc.). For very low numbers, I strongly
recommend disabling DEBUG_GC in gc.c, too.

Implementation: The gc is a "textbook" mark & sweep algorithm, except
that marker bits are stored in a hash set. The reason for this is that,
unlike for most gc'd systems, our addresses are indirect; thus, using them
to store information is unlikely to give us a significant benefit (this
becomes significant when testing whether an object has been touched al-
ready; here, hash sets have significantly better spatial locality). (All
right, I'd have to make measurements before stating something like this...)

To handle all segment types, I used a dynamic dispatch approach (cf.
get_seg_interface()). After this, everything else is straightforward.

Let me know if this breaks some new stuff or fixes old bugs.

Oh, and yes, we can go after savegames now.

-- Christoph