[Gc] Using LARGE_CONFIG flag (was: Too Many Heap Sections)

Boehm, Hans hans.boehm at hp.com
Wed Jan 4 11:39:38 PST 2006

The LARGE_CONFIG flag can be set directly if you use Makefile.direct to
build, which I suspect is rarely done these days.  The current gc7alpha
tree supports --enable-large-config, but that won't help you at the
moment.  In older versions, if you use the autoconf-based build
procedure, I think your best bet is indeed to add


to configure.in.

Under normal circumstances, this flag should only matter for GC build
time.  It is not needed for compiling clients, since it only affect the
sizes of GC-internal tables.  (The answer is more complicated if you use
the inline allocation primitives, which I don't recommend for most
purposes.  If you are using gc_inl.h or gc_inline.h, ask again.)

Normally the only build option that must be consistent between client
code and the GC build is GC_THREADS (or the system-dependent version),
and that's needed to arrange for preprocessor-based interception of
thread creation calls, etc., so that the GC can know which threads
exist.  All the other GC configuration flags affect only the GC build
(with the above disclaimer for inline allocation).

The other macro that is intended to be used in client code is GC_DEBUG.
But it is not needed for the GC build.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of A.T.Hofkamp
> Sent: Wednesday, January 04, 2006 4:07 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Using LARGE_CONFIG flag (was: Too Many Heap Sections)
> Hello all,
> First of all: Thank you Hans Boehm, for this wonderful library!!
> The gc library is being used here in the runtime system of 
> applications 
> generated by our in-house compiler tool chain.
> Installation of the gc library and its use are thus done by 
> different persons 
> from different machines.
> All machines have the Linux operating system with Intel 32bit 
> processors, 
> although some use RedHat Fedora Core 3, and others use RedHat 
> Enterprise 4. 
> Both distributions use the same set of C libraries afaik.
> One of the users of the compiler chain also had this 'Too 
> many heap sections' 
> problem, at the end of the application (the final output of 
> the program did 
> appear).
> Lothar Scholz wrote:
> > You must compile with LARGE_CONFIG defined. For version 6.6 this
> > means:
> We are currently using 6.5 . Maybe I should upgrade?
> > The makefiles in the garbage collector must be patched so that the 
> > LARGE_CONFIG symbol is defined. This means that in the 
> windows build 
> > file "gc.mak" we must add /D "LARGE_CONFIG" to line 118 (release 
> > build) and line 300 (debug build).
> This is confusing to me.
> Are you refering to makefiles of gc or to makefiles of the 
> application being 
> linked to gc?
> In the former case, Makefiles are generated from ./configure, 
> so it would seem 
> that configure.ac should need to be changed instead, or am I 
> missing something 
> here?
> (in the latter case, I would just need to change the flags 
> used to compile the 
> generated applications).
> Another thing that worries me with this flag is consistent 
> use of it at both 
> build times (ie at install-time of the gc lib, and at 
> build-time of the 
> application using gc-lib).
> If the answer to the former question is 'change the make (or 
> configure) of gc 
> sources', then is it harmful if I define the LARGE_CONFIG symbol at 
> install-time of the gc lib, and not at build-time of the 
> application, or vice 
> versa?
> In particular, since the two above builds are in general performed at 
> different machines by different users.
> Thank you very much for your time,
> Albert
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list