Memory Allocation : Static or Dynamic?

[swornavidhya.mahadevan]

Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.

Sworna vidhya

[Antoninus Twink]

On 8 May 2008 at 16:58, sw********************@gmail.com wrote:

Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.

Definitely use dynamic allocation if there's a serious risk of running
out of memory (and as a general principle, don't allocate large arrays
on the stack). If malloc() fails, you can detect this (it will return a
null pointer) and attempt to recover or exit cleanly. If you run out of
static memory for your automatic variables, the most likely outcome is
that the heap will become corrupted without warning. If you're lucky,
your program will quickly segfault; if your unlucky, you could go on for
hours processing corrupted data.

What's going on is that in your process's virtual address space, memory
is arranged like this:

-----------------------
| |
| STACK |
| (grows downwards) |
| |
-----------------------
| |
| FREE MEMORY |
| (available for the |
| stack or heap) |
| |
-----------------------
| |
| HEAP |
| (grows upwards) |
| |
-----------------------

So if you run out of free memory and overflow the stack, you can see
that bad things will happen.

[Walter Roberson]

In article <4f**********************************@u6g2000prc.g ooglegroups.com>,
<sw********************@gmail.comwrote:

>Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.

Sounds like a homework question to me...

But anyhow: The failure of dynamic allocation has well-defined
results: all of the dynamic allocation functions have methods
of indicating that they were unable to allocate more memory. This
allows you to cleanly detect and take action when memory is full.
Static memory has no defined method of indicating failure of
allocation, so you cannot cleanly detect and take action in
such cases.

If there is a failure of static memory allocation, then *some*
systems will generate a signal that can be handled through
the signal handling mechanism, but C89 at least does not define
a signal for this condition and does not document it as a
possibility, so any such signal would be an OS extension, not part of C
itself. And in C89, if the system itself raises any of the signals
defined specifically in C89, then behaviour of the program
after returning from the signal handler is undefined -- all of
the C89- defined signals are for conditions that are typically
fatal on most operating systems. (Note: if the program itself
used raise() to raise one of the C89- defined signals, then
returning from the signal handler -is- well defined.)

I would have to look up the details of the signals that C99 defines
to see if there are any of them for which returning from the signal
handler is well defined. C99 differs slightly from C89 in that
there are operations (such as overflow of a signed integer) that C89
just leaves the behaviour completely undefined, but for which C99
says that the behaviour is undefined or that the system may optionally
raise an implementation-defined signal. This is where the language
lawyers make their money, arguing about the difference between
behaviour that is -always- undefined, vs behaviour that the
implementation may define as being undefined!
--
"All human knowledge takes the form of interpretation."
-- Walter Benjamin

[Walter Roberson]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>What's going on is that in your process's virtual address space, memory
is arranged like this:

>-----------------------
| |
| STACK |
| (grows downwards) |
| |
-----------------------
| |
| FREE MEMORY |
| (available for the |
| stack or heap) |
| |
-----------------------
| |
| HEAP |
| (grows upwards) |
| |
-----------------------

>So if you run out of free memory and overflow the stack, you can see
that bad things will happen.

You truly are an amazing mind-reader! I don't know how you do it!!
*Knowing* with certainty that the original poster is now and will
always be using a system on which the stack grows downwards
and the heap grows upwards.

It doesn't happen that way in the system I'm using right now (a
general-purpose system that at one time was the market leader in
several different computing niches), and it doesn't happen that way
when you start dealing with threads; and it isn't unusual for it not to
happen that way once you start considering where -exactly- shared
libraries get mapped into memory...

--
"It's a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers

[Antoninus Twink]

On 8 May 2008 at 18:37, Walter Roberson wrote:

It doesn't happen that way in the system I'm using right now (a
general-purpose system that at one time was the market leader in
several different computing niches), and it doesn't happen that way
when you start dealing with threads; and it isn't unusual for it not to
happen that way once you start considering where -exactly- shared
libraries get mapped into memory...

Nonetheless, as a schematic picture to have in mind, it's very valuable.

[Eric Sosman]

Walter Roberson wrote:

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>[...]
So if you run out of free memory and overflow the stack, you can see
that bad things will happen.

You truly are an amazing mind-reader! I don't know how you do it!!
*Knowing* with certainty that the original poster is now and will
always be using a system on which the stack grows downwards
and the heap grows upwards.

Not only that, he's discovered that static memory
is allocated on the stack!

--
Er*********@sun.com

[Antoninus Twink]

On 8 May 2008 at 19:05, Eric Sosman wrote:

Not only that, he's discovered that static memory
is allocated on the stack!

Ahem, yeah, good spot... Maybe it's just because static and stack sound
alike, but certainly I read into the OP's question that he was
contrasting dynamic and automatic allocation.

[pete]

Antoninus Twink wrote:

If you run out of
static memory for your automatic variables,

ITYM "static memory for your static variables,"

the most likely outcome is
that the heap will become corrupted without warning.

--
pete

[Antoninus Twink]

On 8 May 2008 at 21:35, pete wrote:

Antoninus Twink wrote:

>If you run out of
static memory for your automatic variables,

ITYM "static memory for your static variables,"

ITIM "stack memory for your automatic variables"... it's been a long day
:)

[cr88192]

<sw********************@gmail.comwrote in message
news:4f**********************************@u6g2000p rc.googlegroups.com...

Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.

static memory is good for fixed-memory buffers (it will never need to be
freed or made any larger).

however, note that static memory is also allocated as a part of the app's
initial process image, so it will either be available, or the app will fail
somehow early in app startup (like, an app that as soon as you try to start
it, either the OS refuses to load it, it crashes, or the OS crashes).

also note that, because of the fixed nature of static memory, what is
located there can't be used by elsewhere (it is like putting a big crate in
ones' house... one can put things in the crate, but otherwise this space is
unusable, and would one rather have a house full of empty space, or filled
with odd-sized crates?...).

one is either limited by all these odd-sized crates, or all of these crates
form a big horrible mess...
otherwise, dynamic memory is a lot more adaptable, and I would recommend
this as a general rule unless one has some specific reason to use large
static buffers.

after all, if dynamic memory were not useful, why would it have been
implemented and used in the first place, when static memory is so much
simpler?...

Sworna vidhya

[Malcolm McLean]

"Antoninus Twink" <no****@nospam.invalidwrote in message

On 8 May 2008 at 16:58, sw********************@gmail.com wrote:

>Which allocation (Static / Dynamic) is suitable for the situation when
we are trying to allocate for a overloaded memory when the memory is
full and no space to allocate.
What will happen if both the allocation is impossible.

Definitely use dynamic allocation if there's a serious risk of running
out of memory (and as a general principle, don't allocate large arrays
on the stack). If malloc() fails, you can detect this (it will return a
null pointer) and attempt to recover or exit cleanly.

Another good strategy is to allocate a big enough static array. Then the
program will not load at all if there isn't enough memory to run, and will
not exit with an error code.

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