[Gc] Re: Determining alignment constraints
hans.boehm at hp.com
Thu May 11 17:30:04 PDT 2006
I've been thinking about this. I suspect you're right that we should do
something along these lines. Unfortunately, it's a bit more complicated
than what you suggest, since:
- If you do add a byte at the end, you really don't want the collector
tracing the last word, since it's guaranteed to not contain a pointer.
And I suspect that the probability of causing an extra cache miss as a
result is fairly high. I think that's not fundamentally hard; we just
need different "kind"s for objects with and without the extra byte.
- Malloc redirection should continue towork, and probably should add the
extra byte. This seems to be a little ugly, given the way
REDIRECT_MALLOC currently works.
- It does add one extra addition to the allocation path. On modern
machines, it's not clear that matters at all, especially if it's done by
a macro in the caller. (Currently the addition is done as part of a
table lookup which we need anyway.)
The bottom line is that I think this should happen, but it's probably
not a trivial amount of work.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Petter Urkedal
> Sent: Wednesday, May 10, 2006 3:25 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: Determining alignment constraints
> 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
> > 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
> 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);
> #ifdef GC_DONT_ADD_BYTE_AT_END
> # 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.]
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc