Re: malloc() and alignment
- From: Eric Sosman <esosman@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 01 Apr 2007 21:36:02 -0400
Francine.Neary@xxxxxxxxxxxxxx wrote:
I've been trying to understand the design decision to have one (well,
three of course, but essentially one) allocation function that returns
a pointer guaranteed to be aligned for any type.
It seems to me that there's a tradeoff here between flexibility and
efficiency. It's easy to imagine on a 64-bit machine that, say, a long
or a pointer would need to be aligned at an 8-byte boundary. Then if
you have a program with a large number of strings, for example, then
you'd potentially be losing 7 bytes of memory for each one! (I guess
chars can always take any alignment)
I'd say the situation would be greatly improved by having eg three
types of allocation function:
1) malloc, generic allocator, same as current malloc
2) malloc_char, returns a pointer only guaranteed to be aligned for
char
3) malloc_int, same but for int.
Is there a good reason something like this isn't in the Standard? And
no implementations seem to have a facility like this either.
It might be instructive to implement your own malloc()
et al. to gain familiarity with some of the issues. There's
a fairly simple version in K&R (the original; I imagine it's
also in K&R II but I don't know for sure) that you could use
as a starting point.
One thing you'll probably discover is that malloc() often
reserves a little more space than is requested, space in which
it can park some housekeeping data. That data typically takes
at least as much space as a size_t, perhaps more. It's surely
most convenient if the housekeeping data itself is properly
aligned, which in turn influences the alignment of the entire
inflated chunk. And if you already need alignment sufficient
for a size_t, it's usually no hardship to provide "strictest"
alignment.
Of course, not all allocators follow the straightforward
K&R style. Some, for example, avoid storing housekeeping data
along with every allocation by allowing the address itself to
imply the housekeeping: If the address is in THIS region of
memory, it refers to an object of THAT size and we need not
store the size explicitly. (This is one reason why realloc()
might fail when shrinking an area.) Such an allocator might
be able to dish out single-byte allocations without undue
penalties, but those I've actually seen in practice have used
a larger "minimum allocation" size.
Long ago, c.l.c. debated whether malloc(1) needed to provide
memory that was properly aligned for double, say, in the common
situation where sizeof(double)>1. One side stuck to the letter
of the Standard: the returned value had to be properly aligned
for any type, and that was that. The other side pointed out that
any attempt to store a double in the 1-byte region would invoke
undefined behavior anyhow, hence no strictly conforming program
could run afoul of looser alignment for small allocations; the
difference made no difference. If I recall correctly, the strict
Standard constructionists carried the day, but it was more due
to volume than to virtue.
--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx
.
- Follow-Ups:
- Re: malloc() and alignment
- From: Keith Thompson
- Re: malloc() and alignment
- References:
- malloc() and alignment
- From: Francine . Neary
- malloc() and alignment
- Prev by Date: Re: when can realloc fail?
- Next by Date: Re: About Union's question
- Previous by thread: Re: malloc() and alignment
- Next by thread: Re: malloc() and alignment
- Index(es):
Relevant Pages
|
