GC and Mercury

[Fergus Henderson]

On 15-Mar-1998, Darius Blasband <darius at phidani.be> wrote:
> >We plan to avoid this overhead, by building static tables that
> >specify the stack layouts.  The type descriptors for reachable
> >heap objects can be computed from the type descriptors for the roots.
> 
> I don't know enough of mercury to decide whether this would be enough...
> In YAFL, for instance, it would have been totaly inadequate. 

Why?

If your language has what in Haskell would be called existential types,
then you need to store type descriptors with any values whose type
is not known until runtime.  (A reference which might point to any
of several derived classes falls into this category.)
However, for those parts of your program which are not using existential
types, then you don't need to store type descriptors.

For example, in C++ many objects do not have vtables.
If you have stack layout information available, then the garbage
collector should be able to avoid the need for any type descriptor for
those objects.

> >In fact the current Boehm collector does support incremental GC.
> 
> How does it handle write barrier ? Hardware fault ?

Yes, it uses the OSes VM support.

> Well, I guess you know my position on Boehm. I do understand it
> was the way to go whn developing Mercury. If one aims at moving
> Mercury in the industrial world, I believe that both from a quality
> and a performance point of view, it is wiser to consider replacement.

Well, conservative GC is a religious issue, I guess.
For safety critical software, I'd agree. 
But it does seems to work pretty well in practice.

---------------------
>From boehm_gc/README:
---------------------

Incremental and generational collection is effective in reducing
pause times only if the collector has some way to tell which objects
or pages have been recently modified.  The collector uses two sources
of information:

1. Information provided by the VM system.  This may be provided in
one of several forms.  Under Solaris 2.X (and potentially under other
similar systems) information on dirty pages can be read from the
/proc file system.  Under other systems (currently SunOS4.X) it is
possible to write-protect the heap, and catch the resulting faults.
On these systems we require that system calls writing to the heap
(other than read) be handled specially by client code.
See os_dep.c for details.

2. Information supplied by the programmer.  We define "stubborn"
objects to be objects that are rarely changed.  Such an object
can be allocated (and enabled for writing) with GC_malloc_stubborn.
Once it has been initialized, the collector should be informed with
a call to GC_end_stubborn_change.  Subsequent writes that store
pointers into the object must be preceded by a call to
GC_change_stubborn.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.