[Gc] Re: Determining alignment constraints

Petter Urkedal petter.urkedal at nordita.dk
Fri May 12 10:44:06 PDT 2006


On 2006-05-11, Boehm, Hans wrote:
> 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:

I'm glad you liked the idea, and I do realise from the code that there
is a lot of tuning put into this.

> - 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.

You are probably right.  I assumed the sizes for non-atomic alloc would
commonly be a multiple of the word size, and thus the last word would be
zero.  But this is not the case for calculated sizes like
sizeof(struct char_array_header) + n*sizeof(char).

Just an idea:
The two kinds you suggest are, in other words, for objects with or
without a possible pointer in the last word.  Since the assumption of
non-pointer last word also holds for any object with a non-word-multiple
size, it may be worth trying to exploit both kinds for GC_malloc_compat:
    kind = GC_MALLOC_ALIGNED_KIND + !!(size % sizeof(GC_word))

> - 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.

Hmm, I don't see any problem with the definitions of malloc() and free()
in malloc.c at least (my GC_DONT_ADD_BYTE_AT_END should be undefined
during compilation of libgc).

> - 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.)

So, separate functions and different size maps, then we're sure.

Petter

> > -----Original Message-----
> > 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/
> > 
> 
> _______________________________________________
> 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