Incremental garbage collection (was: Re: [Texmacs-dev] Boehm-gc-texmacs gc behavior)

[David MENTRE]

Joris van der Hoeven <address@hidden> writes:

> When resuming the garbage collection, we mark the objects accessible
> from b:
>
>       a(1)  -->  u(0)
>       ...
>       b(1)  -->  t(1)
>
> This leaves us with the unpleasant situation that u is not marked,
> although it is accessible. It is not clear to me how Boehm deals
> with this situation. Any ideas?

I think the Boehm GC is tracking modification to already marked memory:
set the marked pages as unwritable (using mprotect) and react on page
faults (re-do a mark phase for modified pages).

See:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html
*Generational Collection and Dirty Bits*

[...]
If it does not complete, we return control to the mutator, and perform
small amounts of additional GC work during those later allocations that
cannot be satisfied from small object free lists. When marking
completes, the set of modified pages is retrieved, and we mark once
again from marked objects on those pages, this time with the mutator
stopped.

We keep track of modified pages using one of several distinct
mechanisms: 

We keep track of modified pages using one of several distinct mechanisms:

   1. Through explicit mutator cooperation. Currently this requires the
      use of GC_malloc_stubborn, and is rarely used.

   2. (MPROTECT_VDB) By write-protecting physical pages and catching
      write faults. This is implemented for many Unix-like systems and
      for win32. It is not possible in a few environments.




I may be wrong. If you want to dig into this GC subject, I would advise
you to read the Further Reading section at the end of Boehm's page
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/). 

You'll find a french description of the OCaml GC (and a general
desscription of GC mechanisms) at:
http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/index.html (look at
chapt. 9)

In english:
http://caml.inria.fr/oreilly-book/html/index.html (also chapt. 9)

Yours,
d.
-- 
 David Mentré <address@hidden>