[Gc] Re: Determining alignment constraints
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.
void *GC_malloc(size_t); /* also defined as external symbol */
# 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.
[Hans: Sorry for the duplicate again.]
More information about the Gc