Re: Implementing a Garbage Collector for C++

=20

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of Maxime=20
> Chevalier-Boisvert
> Sent: Thursday, August 27, 2009 3:13 PM
> To: [email protected]
> Subject: [gclist] Implementing a Garbage Collector for C++
>=20
> Hello,
>=20
> I'm interested in writing a generational garbage collector in=20
> C++. This is for a Python-like programming language=20
> implementation project. I have used Boehm's garbage collector=20
> before, but I'm worried that it will have noticeable pause=20
> times (unacceptable for interactive programs). Since I can't=20
> really find any other C++ established GCs out there, I have=20
> been thinking of simply writing my own.
>=20
> However, there are two essential ingredients I need for this:
> - Some kind of write barrier mechanism that will notify my=20
> collector when something is written to a part of the heap
> - A way for me to know the addresses and sizes of the stack,=20
> heap and global storage (the root sets)
>=20
> Would anyone happen to know how to implement write barriers=20
> (and how to get the stack, heap and global storage=20
> information) on the Linux platform=20
> <http://www.linuxquestions.org/questions/#>?
>=20
> As an alternative, if you know of C++ GCs other than Boehm, I=20
> would also be interested.
>=20
> - Maxime
>=20
Our collector in fact implements those, though the collector only supports =
write barriers at page granularity, using either the VM system, or explicit=
 GC API calls for write accesses.  (The latter is not well-tested, and prob=
ably requires some work.)  You need to call GC_enable_incremental() toturn =
this on.

The problems with this approach are:

- System calls that write to the heap are an issue with the normal Linux im=
plementation that catches SIGSEGVs.  You can't reliably recover from such f=
aults if they occur in the kernel.  (We provide some interfaces to get arou=
nd that, but ...)

- The coarse granularity may be a performance issue, though it seems to wor=
k acceptably in many cases.

- Getting the GC code to do this correctly sems tricky, and the GC becomes =
vulnerable to subtle OS bugs that not many others care about.  Telling the =
difference may be hard.

- The particular GC algorithm that we use may still require an appreciable =
pause for the final update at the end.  The default collector configuration=
 tries to limit this to 50msecs (tunable), and I usually see times not much=
 more than this.  But YMMV.

Hans=