Investigation of Boehm's GC as GCC GC

LaurynasBiveinis

Current status

Conservative marking works. Work in progress on exact marking using auto-generated custom marking routines by gengtype. This might be reused for other collectors too.

Submitted patches

  1. http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01267.html

  2. http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01071.html

  3. http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00695.html

Latest performance results

http://gcc.gnu.org/ml/gcc/2006-07/msg00520.html

Old performance results

http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01267.html

Tech notes

The results of previous investigation performed few years ago can be found at http://gcc.gnu.org/ml/gcc/2002-08/msg00837.html. Note that it has different design.

With a simple implementation of ggc_alloc_stat() by means of GC_MALLOC() and ggc_collect() by GC_collect(), GCC builds and compiles small programs. With anything larger it fails with

../../gcc-boehm-test/gcc/libgcc2.c:32:2: error: invalid preprocessing directive #include
[...]

This is caused by collecting allocated nodes from ident_hash prematurely. This issue can be resolved by registering GC roots for the identifier table. Since table might be relocated and expanded during compilation, currently it is done before every collection. See ggc_stringpool_roots, ggc_register_stringpool_roots(), ggc_unregister_stringpool_roots() and their usage in ggc_collect.

The other malloc()'ed memory areas that contain pointers do not move. It is OK to register them once per lifetime, see register_gty_roots() in ggc-boehm.c.

With these changes GCC bootstraps. The code can be found in boehms-gc branch.

Does Boehm's GC support reallocation of non-atomic data structures?

Things to do if this code is going to be in production

Weak pointer support in Boehm's GC

The collector in branch contains my own patch for weak pointer support.

Custom marking tech notes

gt_types_enum_free_list_obj = 0 is required because Boehm's GC may invoke marker routine on an object residing on free list. Such object contents are cleared except the first word, which is a linked list pointer to the next object. Since type id is after the allocated memory, free list objects will be recognized as such.

None: BoehmGCForGCC (last edited 2008-01-10 19:39:01 by localhost)