[Gc] Re: Determining alignment constraints

Boehm, Hans 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.

Hans

> -----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 
> 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);
>     #ifdef GC_DONT_ADD_BYTE_AT_END
>     #  define GC_malloc(bytes) GC_malloc_compact(bytes)
>     #else
>     #  define GC_malloc(bytes) GC_malloc_compact((bytes)+1)
>     #endif
> 
> 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.
> 
> Regards,
> Petter Urkedal
> 
> 
> [Hans: Sorry for the duplicate again.]
> _______________________________________________
> 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