malloc(allocator) aligned by 8 or 16 byte

[shaanxxx]

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

 

[Ian Collins]

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

It doesn't. It guarantees the address is suitably aligned for any type.
This has to be the case because malloc returns a void* which can be
assigned to any pointer type.

 

[Richard Heathfield]

shaanxxx said:

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

The C language standard makes no such guarantee.

 

[Richard Tobin]

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

-- Richard

 

[Michal Nazarewicz]

why malloc (allocator) guarantees that address return by them will be
aligned by 8 byte ( on 32bit machin ) or 16 byte (64 bit machin) ?

IIRC malloc() (on success) is guaranteed to return address that is
aligned so that any object can be stored correctly. Why it is exactly 8
or 16 bytes you should check in your compiler's documentation.

 

[shaanxxx]

It doesn't. It guarantees the address is suitably aligned for any type.
This has to be the case because malloc returns a void* which can be
assigned to any pointer type.

http://g.oswego.edu/dl/html/malloc.html

if you read this document, you will find that author is little keen
about keeping alignment at eight byte.

 

[Charlie Gordon]

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

long double could have such a requirement.
long long could be 128 bits on a 64 bit machine, and have the same
requirement.
almost anything at all can have such a requirement on a DS9K

 

[Richard Bos]

http://g.oswego.edu/dl/html/malloc.html

if you read this document, you will find that author is little keen
about keeping alignment at eight byte.

Perhaps, but he's writing one for Unix. It may be that on his variant of
Unix, 8 bytes are a reasonable granularity for memory. On some systems
it may be larger, on some smaller. On some, it may be 1 byte. On some, a
whole sector of 256 bytes. It all depends on the system; ISO C says
nothing about this, except that the memory returned by malloc() must be
aligned suitably for any object type - but again, how strict object must
be aligned depends on the system.
As for why these different systems require their respective alignments
to be as strict as they are - that, too, varies with the system. On some
it's just faster because of how their microprocessors work. On some
others it might only be more convenient because of the OS's memory
handler. If you want to know, read your implementation's, your OS's, and
your hardware's manuals. ISO C, and therefore comp.lang.c, cannot tell.

Richard

 

[pete]

Perhaps, but he's writing one for Unix.

And also,
"This article is now out of date,
and doesn't reflect details of current version of malloc."

 

[shaanxxx]

And also,
"This article is now out of date,
and doesn't reflect details of current version of malloc."

where i can find the current version of malloc ?

 

[Richard Bos]

where i can find the current version of malloc ?

If you think that there is a real answer to that question, you are not
yet competent enough to understand the details of any implementation of
such a function.

Richard

 

[Flash Gordon]

shaanxxx wrote, On 13/09/07 07:55:

where i can find the current version of malloc ?

There is NO one "current version of malloc." Each imlpementation has its
own implementation of malloc, the source of some versions are available,
others are not. Where to get it, if it is available, depends on your
implementation, so ask somewhere that talks about your implementation.

 

[Keith Thompson]

where i can find the current version of malloc ?

There is no such thing as "the current version of malloc".

The malloc function is specified by the C standard, as is its required
behavior. Every conforming C implementation must provide an
implementation of the malloc function; as long as it meets the
requirements, no implementation's malloc is more or less correct than
any other.

 

[Keith Thompson]

Presumably on those systems there are objects that have to be aligned
on 8- or 16- byte boundaries. For example, it's quite likely that a
double is 8 bytes long and has to be 8-byte aligned. Even if it
doesn't *have* to be aligned, it may be more efficient if it is.
This varies from system to system - you can't rely on it.

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

Actually the standard requires the memory to be aligned for any type
whether it's big enough or not (though if an implementation violated
this rule, it's not clear that a program could detect it).

I can't guess what type it is on the 64-bit machine that requires
16-byte alignment.

Possibly none. malloc is free to use stricter alignment than it has
to (and there might be good reasons to do so).

 

[Richard Tobin]

Since malloc() doesn't know what kind of object you're going to store
in the memory, it has to make sure it's aligned for any kind (or at
least, any kind that will fit).

[/QUOTE]

Actually the standard requires the memory to be aligned for any type
whether it's big enough or not (though if an implementation violated
this rule, it's not clear that a program could detect it).

And if you can't detect it, the standard doesn't require it.

You could probably (in practice) detect it by casting the pointer to
some integer type, examining the low order bits, and trying to store
an object at an address you determine to be misaligned within a large
enough block. But since the standard doesn't require that the
conversion of pointers to integers work in any particular way, you can
only do it in practice, not theory.

-- Richard

 

[Richard Heathfield]

Keith Thompson said:

The malloc function is specified by the C standard, as is its required
behavior. Every conforming
hosted

C implementation must provide an implementation of the malloc
function;

<snip>

 

[shaanxxx]

Perhaps, but he's writing one for Unix. It may be that on his variant of

I think , malloc is just wrapper on some os call (brk (unix) and
VirtualAlloc (Windows)). So chunk or memory management done by malloc
will be same for all the kind of OS.

please educate me how malloc algorithm will be different on different
on OS ?

 

[Chris Dollin]

shaanxxx wrote:

I think , malloc is just wrapper on some os call (brk (unix) and
VirtualAlloc (Windows)).

Could be. (Needn't be.) It can /use/ those features without being
a wrapper round them. It doesn't /need/ to use them, either.

So chunk or memory management done by malloc
will be same for all the kind of OS.

No.

Each implementation can have /it's own/ `malloc`. There's no need
for different implementations to use the same code. There's not
even any need for the /same/ implementation to use the same code:
it could provide multiple different implementations, selected at
link-time.

please educate me how malloc algorithm will be different on different
on OS ?

/Typically/, I have read, mallocs will ask the OS [if there is one] for
/large/ chunks of memory at a time, and sub-divide those chunks as they
need for the client code [1]. How they do that sub-division is their
business. They might use a buddy system, or a Big Bag Of Pages, or a
freelist, or several freelists arranged by size. Or something.

[1] Partly because system calls can be significantly more expensive
than function calls, and because the system memory management
might not be able to do the same things as malloc/free/realloc
need to do -- like free memory between two pieces of still-
mallocated memory.

 

[Keith Thompson]

And if you can't detect it, the standard doesn't require it.

There is at least one real consequence of the requirement. Converting
from one pointer type to another invokes UB if the resulting pointer
is not correctly aligned. So this:

long double *ptr = malloc(1);

does *not* invoke UB even if you can't store a long double in the
allocated memory.

But if the implementation doesn't impose alignment requirements on
converted pointers, but does impose alignment requirements on objects,
then an implementation can get away with having malloc(1) return a
misaligned pointer without any portable program being able to detect
it.

What I mean by the above is, for example, if a long double object must
always be aligned on an 8-byte boundary (attempting to read or write a
misaligned long double invokes UB), but all pointers are just byte
pointers, and constructing a 'long double*' that points to an odd
address doesn't do anything nasty.

[...]

 

[Flash Gordon]

Chris Dollin wrote, On 13/09/07 13:57:

Could be. (Needn't be.) It can /use/ those features without being
a wrapper round them. It doesn't /need/ to use them, either.


No.

Each implementation can have /it's own/ `malloc`. There's no need
for different implementations to use the same code. There's not
even any need for the /same/ implementation to use the same code:
it could provide multiple different implementations, selected at
link-time.

<snip>

It could even allow you to select the implementation at run time of the
application. One *very* big and well known company has even done this
with the C library for its high end OS.