Investigation of Boehm's GC as GCC GC
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.
Latest performance results
Old performance results
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
Top-level configure should build the collector on host only if --with-gc=boehm is given.
Top-level configure should be taught to pass on appropriate --enable-threads value. Right now the collector must be configured with --disable-threads by hand.
- Solve the weak pointer support patch issues, see below.
- The built host library should be renamed to libgc from libgcjgc. Target library can be left alone.
Boehm's GC make check target should be integrated into main make check.
Weak pointer support in Boehm's GC
The collector in branch contains my own patch for weak pointer support.
For production, it probably should be changed to http://www.eideticdew.org/culibs/bdwgc-rn.html or something else that would be accepted upstream.
In my patch, is memory size increase of struct disappearing_link something to be concerned about?
- Is there a need for a external function for unregistering all the weak pointers?
Could the weak pointer callback be implemented with http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/759 ?
- How should the case of registering the same link twice be handled?
- Boehm's GC appears to support pre-standard C dialects. Should this part be tested for the patches submitted upstream?
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.