[Gc] Re: Determining alignment constraints

Petter Urkedal petter.urkedal at nordita.dk
Wed May 10 03:24:45 PDT 2006

On 2006-05-09, Boehm, Hans wrote:
> > 
> > > Are there other properties that it would be useful to 
> > export as a macro?
> > 
> > Yes: the version number.  Ideally, both via macro(s) and C 
> > symbol(s) so that one can check that the headers that were 
> > used correspond to the shared library at hand (zlib uses this 
> > technique).
> That's actually mostly there, but I think the header is not currently installed.  See version.h in the main directory.  This does result in a GC_version symbol you can check dynamically.
> > 
> > > I guess my view is that you shouldn't install a nongeneric build 
> > > someplace where autoconf can find it.  On the other hand, the 
> > > build-time options do seem to be useful for some applications that 
> > > include the library, and do not install it separately (of which we 
> > > currently probably have too many).
> > 
> > For 7.x, are there plans to limit compile-time switches in 
> > order to reduce the need to bundle the library within 
> > application packages?
> > 
> That has been a long term goal.  I think it's now mostly OK, except I'm not entirely enthusiastic about some of the compromises.

After reading the recent "Determining alignment constraints"-thread, it
occured to me that maybe the collector could have dedicated functions
for DONT_ADD_BYTE_AT_END case, e.g.

    GC_malloc                       GC_malloc_compact
    GC_malloc_atomic                GC_malloc_atomic_compact
    GC_malloc_uncollectable         N/A
    GC_malloc_atomic_uncollectable  N/A
    GC_malloc_stubborn              GC_malloc_stubborn_compact
    GC_malloc_many                  GC_malloc_many_compact
    GC_generic_malloc               GC_generic_malloc_compact
    GC_generic_malloc_many          GC_generic_malloc_many_compact

with definitions

    void *GC_malloc(size_t); /* also defined as external symbol */
    void *GC_malloc_compact(size_t);
    #  define GC_malloc(bytes) GC_malloc_compact(bytes)
    #  define GC_malloc(bytes) GC_malloc_compact((bytes)+1)

etc, so that the *client* can define GC_DONT_ADD_BYTE_AT_END during
compilation.  Or would GC_malloc defined this way be sub-optimal?  I
believe most client code could in fact call GC_malloc_compact instead of
GC_malloc (except for array allocations).

I can propose a patch if it's ok to specialise under the EXTRA_BYTES=0
assumption, rename GC_malloc to GC_malloc_compact etc, and use the above
definition of GC_malloc etc.  Or is there a better way?

In general I think the most important compile time options to remove are
those that affect the semantics of the API calls.

Petter Urkedal

[Hans: Sorry for the duplicate again.]

More information about the Gc mailing list