Amount OF Memory...,

[Pranav]

How Much memory is allocated by the MALLOC when we call the function?
Does it return only the amount requested or it returns memory by
rounding it to the multiple of minimum no of bytes of memory decided
by the implementation?

Thank you,
Pranav

 

[santosh]

How Much memory is allocated by the MALLOC when we call the function?
Does it return only the amount requested or it returns memory by
rounding it to the multiple of minimum no of bytes of memory decided
by the implementation?

There is no general answer. It will obviously vary between
implementations. Many modern implementations allocate memory as pages.
On such systems even a call to malloc(1) will allocate an entire page,
if there is no space in the previously allocated pages. Also malloc
needs to somehow record the size of each allocation to make free work
properly, which is also likely to consume a minimum of few bytes of
overhead.

 

[Richard Tobin]

How Much memory is allocated by the MALLOC when we call the function?
Does it return only the amount requested or it returns memory by
rounding it to the multiple of minimum no of bytes of memory decided
by the implementation?

[/QUOTE]

There is no general answer. It will obviously vary between
implementations. Many modern implementations allocate memory as pages.
On such systems even a call to malloc(1) will allocate an entire page,
if there is no space in the previously allocated pages.

As this answer shows, it depends what you mean by "allocate". There's
the amount of memory returned from malloc() - which might be exactly
the amouint asked for, or might be rounded up - and the amount of
space obtained from the operating system by the implementation, which
will almost certainly be in larger chunks, probably pages.

-- Richard

 

[31349 83652]

Many modern implementations allocate memory as pages.
On such systems even a call to malloc(1) will allocate an entire page,

Whatever amount of memory malloc() returns (if any), you're not
allowed
(under penalty of UB) to access anything but what you asked for.

unsigned char *buf = malloc(42);
if (buf) {
buf[41] = '\0'; /* OK */
buf[42] = '\0'; /* UB, even if malloc returned a 4096 byte page
*/
free(buf);
}

At least I think so

 

[Ben Bacarisse]

Almost always the amount will be rounded up. Fast allocation
algorithms work by rounding up small requests to the nearest power of
two.

Sounds very unlikely. That would map 1->1, 2->2, 3->4, etc.

 

[Keith Thompson]

Almost always the amount will be rounded up. Fast allocation
algorithms work by rounding up small requests to the nearest power of
two. For big allocations you might as well allocate whole pages. I
don't actually know how any common system manages big allocations
internally, but it probably makes management easier to keep the
allocation as whole pages beyond a certain size.

Are you suggesting that, for large allocations, the value passed to
malloc() might as well be a multiple of the page size?

First, there's no portable way to know what the page size is, even if
there is such a thing.

Second, suppose the page size is 1024 bytes. The implementation will
typically need some extra space to keep track of allocations. If you
need 1000 bytes and decide to call malloc(1024), the implementation
might be forced to allocate 2048 bytes; if you had just called
malloc(1000), the metadata could have been stored in the extra 24
bytes.

If the metadata isn't stored contiguously with the allocated memory,
this probably won't apply, but it's still the kind of
micro-optimization that's better left to the implementation. If you
need 999 bytes, just call malloc(999).

 

[Ben Bacarisse]

If the page size is a power of two, then you can do a jigsaw with
powers of two, and avoid fragmentation or long searches. 1 is fine as
a jigsaw piece size.

I must be missing how the rounding helps. If 1 and 2 are fine, why
not 3?

 

[soscpd]

Hello List

Well... this question come in handy. If I have, say, one n dimension
array who points to some struct who, on his initialization time,
points to another struct, like (Just a sample):


typedef struct
{
char ****args;
int **index_args;
} arguments;

typedef struct
{
char ***values;
int *index_values;
} what;

struct
{
what ***ever;
/* ok... I have other stuff in here, but the main question point
is illustrated */
} mystruct;

What should be the best practice on memory allocation? All in one time
or each element, one by one?

To know better what a hell is all that about, I have x elements(char
***values). Each value should receive n arguments (before runtime, and
even on runtime - since some values should change from network input -
I don't know the number of arguments for each value. All must be
dynamic).

Lets say I have:

value[0][index_values[0]]="%s %s %s.\n";

On args, I need:

args[0][index_values[0]][index_args[0][0]]="The";

args[0][index_values[0]][index_args[0][1]]="final";

args[0][index_values[0]][index_args[0][2]]="string";

I'm trying to make this sample very very simple, but this can create a
problem. The application looks too weird to work out this simple task.
In the main context (is not here), this way make more sense (at least
to me, so far .

To:

int myvprintf(const char *format, ...)
{
int rv=0;
va_list arguments_list;

va_start(arguments_list,format);

rv=vprintf(format,arguments_list); /* vprintf here, but I'm using
vsprintf in the real code */

va_end(arguments_list);

if(rv<0)
return EXIT_FAILURE;

return EXIT_SUCCESS;
}


Thanks
Rafael

 

[vippstar]

I must be missing how the rounding helps. If 1 and 2 are fine, why
not 3?

Because 3 is two jigsaw pieces while 1 and 2 are one.

 

[Ben Bacarisse]

Because 3 is two jigsaw pieces while 1 and 2 are one.

I have no idea if that is supposed to be an "aha!" moment or a joke!
Either way, due to the off-topic drift, maybe you could just point me
at something that explains what you think I have missed.

 

[Pranav]

Then, Is there any way to check the amount of memory allocated to the
process? and also any method to check dynamically allocated memory to
the process?

Thank You,
Pranav

 

[Ben Bacarisse]

Then, Is there any way to check the amount of memory allocated to the
process? and also any method to check dynamically allocated memory to
the process?

Yes, but not in standard C (the topic here). Because of the way
allocators work, there is not as simple an answer to the question as
you probably expect. C libraries often have extra functions to let
you ask questions about malloc, and all OSes I've seen give you some
way to find out how much memory a process is using. Ask in an OS
group like comp.unix.programmer (if you are using a Unix-like system)
to get a fuller answer.

 

[Pranav]

K..., One more thing if I do 3 malloc's each 0f size 20 bytes then do
compiler/linker allocates 3 pages of memory or it will utilize a
single page of memory properly? Although malloc is implementation
dependent but you can take any compiler/OS as example to explain..,

Thank You,
Pranav

 

[Ben Bacarisse]

K..., One more thing if I do 3 malloc's each 0f size 20 bytes then do
compiler/linker allocates 3 pages of memory or it will utilize a
single page of memory properly? Although malloc is implementation
dependent but you can take any compiler/OS as example to explain..,

Ask in a group that discusses you system.

 

[Keith Thompson]

K..., One more thing if I do 3 malloc's each 0f size 20 bytes then do
compiler/linker allocates 3 pages of memory or it will utilize a
single page of memory properly? Although malloc is implementation
dependent but you can take any compiler/OS as example to explain..,

Calling malloc won't cause the compiler or linker to allocate
anything. Allocations performed by malloc occur at execution time.

(Nit: It's conceivable that some malloc calls might be transformed
into some sort of compile-time allocation if the compiler and/or
linker can prove that the effect is the same, but I think that's an
unlikely optimization.)

Yes, the behavior of malloc is implementation dependent. Ask in a
newsgroup that deals with your system.

 

[Herbert Rosenau]

K..., One more thing if I do 3 malloc's each 0f size 20 bytes then do
compiler/linker allocates 3 pages of memory or it will utilize a
single page of memory properly? Although malloc is implementation
dependent but you can take any compiler/OS as example to explain..,

That depends completel on the implemenation.

One of the possibilites would be:

At startup the implementation allocates a big block of memory, say 64
MiB for give avay many, many small shuncs requested by calls to
malloc. When that big block will have no more unrecested small chunc
to fullify another request of a small chunc malloc will internally
another big block of say 64 MiB or 128 MiB or 16 MiB to have an are
splitable to new requests of small chuncs.

Another possibility would be that malloc requests only a small number
of coninouse memory to fullify small requests and when malloc comes
with a very big request it may request enough continous pages from the
system separate for that.

Commonly the details of what strategy malloc uses to fullify requests
is hidden by the implementation and may change from version to version
like it changes between differen implementations. When the
implementation is open source you can loog into the source of it -
when not you're out of luck.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Keith Thompson]

Not quite. The OS will round it up internally to a whole number of
pages. This could be minus any control blocks, if the allocation
system uses such things.

Upthread, you wrote:

For big allocations you might as well allocate whole pages.

If "you" refers to the implementation, then I have no argument. If
"you" refers to the user writing a call to malloc, then I disagree.