Re: [Gc]: Problems with GC settings
ivmai at mail.ru
Tue Oct 6 03:13:31 PDT 2009
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
> 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.
And how is this distributed? Typically stand-alone libs have platform-independent somename-devel-version.tar.gz which contains only public headers (include/*.h). If I understand correctly, you can't have a platform-independent 'devel' pack for your library, right?
I agree that we could do something like (add export the features) for GC. Do you have a working patch for it?
> > 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 built in support for GCJ and GCJ-type marking, or Java
Java finalization is out of this list - portable clients should call GC_set_java_finalization(1/0) before GC_INIT().
Agree with the rest (but, as I already noted, the currently 'supported' GC philosophy is different - if the top-level client needs threads then GC should be compiled with thread support, and there is no means for making the top-level client not to use threads if someone compiled GC without threads support or threads are unsupported on the target).
> I know there are other macros that are not explicitly
> 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.
To my opinion (and knowledge of GC internals), a program with minimally sophisticated requirements for GC is a program which uses only GC_malloc (and friends), no more (even no finaization).
If you are building a library which uses GC internally then I don't recommend to build GC as a shared one. There is no "isolate" feature in GC. (I want GC API to be like Java JNI (in respect to GC tuning isolation, eg., different modules (inside a single app) may have different finalize-on-demand/java-finalization policies or different manually-set static data roots) but I don't think it'll emerge in the observed future.)
More information about the Gc