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

[Richard Heathfield]

Pranav said:

How Much memory is allocated by the MALLOC when we call the function?

If it allocates any, it will allocate at least as much as you ask for.
That's as much as the Standard guarantees.

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?

The precise details of the allocation are implementation-specific. To find
out how *your* implementation's malloc behaves, you would do best to ask
in a newsgroup that deals with your implementation.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Pranav wrote:

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]

In article <g8**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

>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.

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

--
Please remember to mention me / in tapes you leave behind.

[31349 83652]

santosh wrote:

Pranav wrote:

How Much memory is allocated by the MALLOC when we call the function?

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 :)

[Malcolm McLean]

"Pranav" <pr*******@gmail.comwrote in message news:

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?

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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Pranav" <pr*******@gmail.comwrote in message news:

>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?

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.

--
Ben.

[Malcolm McLean]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

"Malcolm McLean" <re*******@btinternet.comwrites:

>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.

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. However if the machine demands alignment then you'll have to round to
a minimum of the strictest alignment type. That's a separate issue to the
fast jigsaw algorithm.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Pranav" <pr*******@gmail.comwrote in message news:

>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?

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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>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.

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?

--
Ben.

[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

[pete]

31349 83652 wrote:

santosh wrote:

>Pranav wrote:

>>How Much memory is allocated by the MALLOC when we call the function?

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 :)

That's what I think too.

--
pete

[vippstar]

On Aug 18, 12:34 am, Ben Bacarisse <[e-mail]:

"Malcolm McLean" <[e-mail]:

"Ben Bacarisse" <[e-mail] in message

"Malcolm McLean" <[e-mail]:

>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.

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?

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

[Ben Bacarisse]

vi******@gmail.com writes:

On Aug 18, 12:34 am, Ben Bacarisse <[e-mail]:

>"Malcolm McLean" <[e-mail]:

"Ben Bacarisse" <[e-mail] in message
"Malcolm McLean" <[e-mail]:

>>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.

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?

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.

--
Ben.

[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]

Pranav <pr*******@gmail.comwrites:

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.

--
Ben.

[Gordon Burditt]

>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?

Not in standard C.

Some operating systems have a program called 'ps' which, among other
things, lists some memory statistics about processes. The definitions
of exactly what those memory statistics mean, especially across
different variants of similar operating systems, may be a bit fuzzy.

What is measured may be memory requested from the operating system,
not memory allocated by the program. In particular, the memory
in use number might *never* go down in response to a free().

[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]

Pranav <pr*******@gmail.comwrites:

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.

--
Ben.

[Keith Thompson]

Pranav <pr*******@gmail.comwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

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

Imagine you've got several pages of memory from the OS, and several
allocation requests, of varying size but always smaller than a page.
One way of fitting them in efficiently is to divide each page into blocks of
equal size. Then all you need is, for each page, a block size, and an array
of bits telling you whether that block is allocated.
Since page size will be a power of 2, arbitrary block sizes waste a bit of
space. However fundamentally you are right, you could use any sequence of
increasing block sizes and things would still work. It just makes the logic
a bit simpler to use powers of 2.
If pages are large, using a power of 2 makes it easier to implement a
sub-block system, whereby each physical page is divided into several logical
pages. As blocks are freed, they can be united into valid blocks the next
power of 2 up. Then if the hardware demands strict alignment, powers of 2
are almost always the alignment demanded. So in practise blocks are always
powers of 2, although a power of 2 might not be delived to the user, if
guard bytes are placed before and after the block to detect buffer overruns,
for example.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message

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

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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Herbert Rosenau]

On Mon, 18 Aug 2008 10:42:51 UTC, Pranav <pr*******@gmail.comwrote:

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]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"