[gclist] Boehm collector vs lazy allocation with demand paging

[Hans Boehm]

On Apr 8,  9:42pm, Fergus Henderson wrote:
> Several memory areas used by the Mercury runtime engine
> such as the Mercury stacks are allocated with a fixed size
> at startup, with the idea being that with demand paging,
> we can allocate much more than we will need, and the OS
> will allocate it lazily for us as we actually use it.
>
> Unfortunately this idea doesn't work with the Boehm collector,
> because the collector scans all of memory, which I think causes
> the memory to allocated (even though the collector is only reading
> it, not writing to it), and which certainly slows down garbage
> collections.
>
If you allocate this memory directly from the OS, then you should
arrange to define your own mark procedure for it.  If you are not using
OS-supplied threads, you can do this on many systems by assigning a
suitable procedure to GC_push_other_roots.

This currently doesn't work well in conjunction with dynamic library
support on some systems (win32 and Irix, mostly) on which dynamic
library data areas are found by enumerating address mappings.  I'm
planning on fixing this for Irix, but I haven't had the time.
I don't know how to fix it for win32.  There should also be a generic
mechanism to exclude areas from the default root set.  But it's not
currently there, either.

If the objects are allocated through the collector, then all the
hooks are there for custom mark procedures.  The marking engine understands
several different kinds of descriptors (object length, bit map, procedure,
optionally stored per object).  If there's demand, I'll generate some
documentation as to how to use these.  GC_malloc_explicitly_typed is a
(admittedly complex) client of this facility.  It uses either a custom
mark procedure, or other kinds of descriptors, depending on the
circumstances.

Hans



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com