Re: hashtable-based marking and cleanups

Olivier Galibert <galibert(a)pobox.com&gt; writes: [I have no time to compile with the patch at the moment, sorry] Do you have an infinite amount of memory too? +/* An estimation (not the exact number) of the number of currently existing l(c)rcords */ +static int object_count; + [..] + quickhash_init (object_count*4); Unless I am going mad the memory overhead is now 4+1 words per object, i.e. 125% (only during the sweep, but does that matter?). I don't think you can really say much about the speed of the GC unless you use one which actually space efficient (and thus has to do more shifts & masks). If you don't want to do the pool thing just yet: What about using a "conservative" garbage collector in the sense that you marked the hash(address)'ed bit in a bit array of size object_count*4. This reduces the sweep array to 4 bits per object, or <6.3%. This doesn't free all free objects (i.e. those that hash to the same value as a referenced object), but by slightly varying the hash function from sweep to sweep (introducing a bit of pseudo-randomness) most of them will be freed later. Does somebody have numbers on the expected ratio of hash clashes for varying hash sizes handy? Well.. Maybe doing the pools is just as easy... Jan P.S. I just spent waaaaaaayyyyy to much time debugging the 21.1.7 unexec problems on Linux, so AFAIC the portable dumper stays whatever the overhead.