[Gc]: Problems with GC settings

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Tue Oct 6 02:01:42 PDT 2009

2009/10/6 Ivan Maidanski <ivmai at mail.ru>:
> So, you export your lib features list
> (i.e. install your config.h along with your .lib or .so),
> right? (Otherwise, a client could be broken if it
> manipulates pointers in threads.)

I only export the features, not the things that were detected by
autoconf. More precisely, the main header ecl/ecl.h includes a file,
ecl/config.h, in which there are conditional definitions of things
like ECL_THREADS, ECL_UNICODE, etc, which the user may need to decide
how to write his/her code.

> The above list, may also include optimization level
> (-DPARALLEL_MARK is essentially an optimization algorithm)
> and the compiler version with which the installed GC lib is built.
> In other words, you want access to the GC internal config (at build time of your project).

Not entirely "internal", but rather things that will affect how I have
to code. A simple thing is whether the garbage collector was
configured using threads. A more sophisticated thing would be whether
it has builti in support for GCJ and GCJ-type marking, or Java
finalization. I know there are other macros that are not explicitely
shown in "./configure --help", but which may affect the way the
garbage collector behaves.

> Another possible solution (which I'm personally use) is:
> 1. have GC lib distinct names: gc.lib is single-threaded and gcmt.lib is an MT-safe one;
> 2. build GC lib (of the required config) along with a project (so that GC would be an internal part of a project).

To enforce each program with minimally sophisticated requirements to
build its own copy of the garbage collector seems backwards, and both
memory and time wasting, specially in a world of software
distributions where almost all libraries are available pre-compiled.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)

More information about the Gc mailing list