[Gc] Re: Determining alignment constraints
ludovic.courtes at laas.fr
Thu May 4 05:41:58 PDT 2006
"Boehm, Hans" <hans.boehm at hp.com> writes:
>> > For 6.X, in some common configurations, GC_malloc(4)
>> returns an object
>> > that's only word aligned, even with ALIGN_DOUBLE set.
>> According to `gcconfig.h', that is currently limited to m68k,
>> PPC with MacOS, and CRIS.
> In the 6.7 version (and I think 6.6), it seems to be defined elsewhere
> as well, in particular for "normal" X86 configurations.
Sorry, does "it" refer to "the `ALIGNMENT' macro"? After a quick grep
through the 6.6 source, I couldn't find it anywhere but in
> Probably the easiest best way to work around the problem for 6.X is to
> build an autoconf test. I believe it's sufficient to allocate two
> objects of the desired size in a row; if they are sufficiently
> aligned, all of them will be.
I had thought about this but is this behavior guaranteed or just
"believed to be guaranteed"? ;-) That makes a significant difference.
Besides, given that the alignment information is already available as a
macro, I still believe that exposing this macro would allow for easier
and more accurate propagation of the information.
However, since `gcconfig.h' does not get installed, we'd have to
propagate the macro definition to another, installed header. I have
various tricks in mind that could be used to do this. Would you like to
add such a macro definition to future `libgc' versions? If so, I could
> The major difficulty with all of this is that the details depend on the setting of GC_all_interior_pointers, which I worked hard, perhaps unwisely, to make a runtime option to avoid multiple copies of the library. If you are using the collector for C/C++ code, you want this turned on, and you want objects to be overallocated by at least one byte in order to deal with one-past-the-end pointers. If you are allocating Guile cells, you probably want this turned off.
> With one-byte-overallocation turned off, you get some other nice alignment properties. In particular small power of 2 sized allocations will be aligned to that power of 2. With the one-byte-overallocation, the extra byte implies that such allocations will actually be a word or two words larger, destroying the alignment.
> This, if you know that GC_all_interior_pointers is turned off, you are guaranteed that GC_malloc(2*sizeof(void *)) will return something that is 2*sizeof(void *) aligned, and that should be true everywhere.
Right, thanks for the trick. However, in Guile, `GC_malloc ()' is going
to be wrapped in a Guile-specific allocation function that may be used
for various kinds of objects, not only cells. That would have been
useful if `GC_all_interior_pointers' was actually passed as an argument
to some variant of `GC_malloc ()': cells could have been allocated with
this turned off, while other arbitrary objects would have been allocated
with this turned on. Anyway, leaving it on should not be a major issue.
> There is also currently a GC_memalign() call, which should always work, but will add some overhead.
It seems that this call is not exported (at least not in 6.6).
> The intent was that this configuration not be changed for "generic" builds of the library. I added a comment to that effect to the appropriate header. Thus in 7.0, you should be able to count on 2*sizeof(void *) alignment everywhere, unless you include and build your own version of the library.
This means that some autoconf or `#ifdef' check must still be done to
know how the available `libgc' works (IOW, to know whether it's a
More information about the Gc