Re: hashtable-based marking and cleanups
> + 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?).
Yes, it does matter. It is usually allocated at the end of
the memory, and since the gc only frees memory, if your malloc
is any decent, the virtual space is given back to the system
when the final free is done.
I don't think this is always possible. If the break is moved, we
can forget about giving the space back to the system. The sweep
phase of GC calls finalization routines, which themselves might
call malloc(). I'm not worried about our code as much as I'm
worried about calls to stuff in X libraries, or to God knows what
MS Windows library.
There is also the perversity of allocating a big block of memory as
an integral part of the process that is supposed to reclaiming
unused memory. GC should not, in theory, require calls to malloc()
to succeed. Again, we're at the mercy of the libraries as far as
the finalization routines are concerned, but we shouldn't be
calling malloc() directly in our own GC code.