[Gc] Re: Determining alignment constraints
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.
> > -----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
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc