Disadvantages of malloc()

[Aire]

On some small-memory systems, is it true that "malloc()" is not supported by
the C library?

Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?

Thanks!

[E. Robert Tisdale]

Aire wrote:

On some small-memory systems,
Is it true that "malloc()" is not supported by the C library?

Why is 'dynamic memory allocation' so avoided on such systems?
What are major problems of using malloc() here?

The comp.lang.c newsgroup
is a good place to get *bad* advice about any particular architecture.

Try the comp.arch.embedded newsgroup instead.

[Dave Vandervies]

In article <k8*********************@bgtnsc05-news.ops.worldnet.att.net>,
Aire <ai*****@zoomit.org> wrote:

On some small-memory systems, is it true that "malloc()" is not supported by
the C library?
All systems claiming to support a hosted C implementation are required
to support malloc.[1]

These days most small-memory systems are freestanding implementations,
which are not required to implement most of the standard library; malloc
is a popular candidate for a part of the standard library to leave out.

Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?

Usually because dynamic memory allocation isn't necessary and makes
possible some problems that are hard to solve in limited environments.

A lot of the regulars here have worked with freestanding implementations
in limited environments and will be able to tell you more than
you ever wanted to know about the details I'm waving my hands over.
comp.arch.embedded (discussing embedded systems, where most freestanding
C implementations are used) might also be able to shed some light on
the subject.
dave

[1] Well, at least if they want people to believe the claim.

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Start with your English classes; only when you've got the point that spelling
is not completely optional are you ready to proceed to the rather more exacting
discipline of programming. --Richard Bos in comp.lang.c

[Malcolm]

"Aire" <ai*****@zoomit.org> wrote in message news:

On some small-memory systems, is it true that "malloc()" is not
supported by the C library?
Yes, some not-so small systems like games consoles don't support it either.
Why is 'dynamic memory allocation' so avoided on such systems?
What are major problems of using malloc() here?

As long as you can declare a global array of reasonable size it is easy to
implement malloc() (call it mymalloc()).
There are lots of reasons for not providing malloc(), but mainly so that the
programmer has complete control over every byte allocated. For instance one
game I wrote used a lot of small allocations of the same size, so I
customised the memory allocator to provide these efficiently. using a
built-in malloc() this would not have been posible.

[Dan Pop]

In <k8*********************@bgtnsc05-news.ops.worldnet.att.net> "Aire" <ai*****@zoomit.org> writes:

On some small-memory systems, is it true that "malloc()" is not supported by
the C library?
It depends on what you mean by small-memory system. A conforming hosted
C89 implementation must provide at least 32k of RAM. Otherwise it can
only be a conforming freestanding implementation and, in this case, it
need not provide a malloc() implementation.
Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?

Dynamically allocated memory has certain overheads that statically and
automatically memory don't. A malloc(100) call would always use more
than 100 bytes of memory, because the malloc() implementation must keep
track at least of the block's size, but typically more data is kept about
each dynamically allocated memory block. Then, there is the effect of
malloc arena fragmentation, caused by multiple allocations and
deallocations. In a pathologic scenario, a significant part of the malloc
arena becomes unusable by the program and, therefore, wasted.

OTOH, if you can't predict the size of a memory block when writing the
code, you have to either overallocate it statically/automatically or
dynamically allocate it. The former alternative may waste even more
memory.

Another issue is what happens when your program runs out of memory.
If it's due to statically allocated memory, it will fail to load.
If it's due to automatically allocated memory, it will crash at
run time. If it's due to dynamically allocated memory, you're still
controlling the situation and have the option on choosing the best way
of proceeding.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Rob Thorpe]

"Aire" <ai*****@zoomit.org> wrote in message news:<k8*********************@bgtnsc05-news.ops.worldnet.att.net>...

On some small-memory systems, is it true that "malloc()" is not supported by
the C library?

Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?

Thanks!

Dan has covered the reasons, I will only add that a lot can be learnt
by reading malloc implementations. There are quite a few good ones on
the web, all of which demonstrate the problems.

[Michael B Allen]

On Tue, 27 Jan 2004 22:31:21 -0500, Rob Thorpe wrote:

Why is 'dynamic memory allocation' so avoided on such systems? What
are major problems of using malloc() here?

Thanks!

Dan has covered the reasons, I will only add that a lot can be learnt by
reading malloc implementations. There are quite a few good ones on the
web, all of which demonstrate the problems.

The stdlib malloc is also usually protected by locks for multithreaded
programs which makes it a little slower than a lockless allocator like
this one:

http://www.ioplex.com/~miallen/libmba/dl/src/suba.c

Of course if you are writing a multithreaded application you have to
be more careful. Suba is also only ~250 lines of code so it might
be a good example to look at or extend if you're exploring memory
allocation. There's nothing fancy about it -- just a circular linked
list of "cells".

Mike

[Old Wolf]

> On some small-memory systems, is it true that "malloc()" is not supported by

the C library?

Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?

It means you run the risk of running out of memory, not to
mention memory fragmentation.

Suppose you have a system with 64K of memory, and your application
does some dynamic allocation. It all works fine, until other
applications are loaded onto the system, and then one day when they
all happen to have malloc'd at once , the system crashes and everybody
blames everyone else's application. This is doubly important if the
crashed happened at an important time (eg. during open heart surgery).

It's far more reliable to allocate all memory at compile-time
(ie. a fixed-size stack, and no malloc calls). You can inspect
your code to ensure that the stack will never overflow.

I have heard of systems that support malloc() (just to be conforming)
but always fail (return NULL). Others just don't bother
with the rigmarole and don't support it.

[xarax]

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

On some small-memory systems, is it true that "malloc()" is not supported by
the C library?

Why is 'dynamic memory allocation' so avoided on such systems? What are
major problems of using malloc() here?
It means you run the risk of running out of memory, not to
mention memory fragmentation.

Suppose you have a system with 64K of memory, and your application
does some dynamic allocation. It all works fine, until other
applications are loaded onto the system, and then one day when they
all happen to have malloc'd at once , the system crashes and everybody
blames everyone else's application. This is doubly important if the
crashed happened at an important time (eg. during open heart surgery).

Open heart surgery with a machine that has 64K memory?

On the reality side, most modern operating systems
today use virtual memory and isolate each application
(i.e., "process") within its own virtual space. E.g.,
address 0x1000 translates to a different piece of real
memory for each application. The system crashes only
when it runs out of paging space on the harddrive. Then
it's a problem of simply running too many processes at
the same time. It's not the fault of the application,
but the users that loaded too many applications on
the same box at the same time.
It's far more reliable to allocate all memory at compile-time
(ie. a fixed-size stack, and no malloc calls). You can inspect
your code to ensure that the stack will never overflow.
That only moves the fragmentation from malloc()
to stackframe management. Stackframe memory and
malloc() memory come from the same place. The
stack frame is fixed-size, but the compiler cannot
determine how much memory is needed for all stack
frames (recursive calls, function pointer calls).

Most real world problems are solved much more
efficiently with malloc() memory than swagging
a giant array on the stackframe. Load up too
many of those kinds of programs and you have
the same problems as too many malloc()-style
programs running at the same time.
I have heard of systems that support malloc() (just to be conforming)
but always fail (return NULL). Others just don't bother
with the rigmarole and don't support it.

Design your C programs to use stack frame
memory and heap memory using prudent policies,
rather than fearing that someday your program
will be ported to a Deathstation2000. Stay
grounded in the real world.
--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!

[Old Wolf]

> > It means you run the risk of running out of memory, not to

mention memory fragmentation.

Suppose you have a system with 64K of memory, and your application
does some dynamic allocation. It all works fine, until other
applications are loaded onto the system, and then one day when they
all happen to have malloc'd at once , the system crashes and everybody
blames everyone else's application. This is doubly important if the
crashed happened at an important time (eg. during open heart surgery).
Open heart surgery with a machine that has 64K memory?

A machine that, say, measures out dosages of medicines, would not
need much memory. Anyway I'm sure you can think of lots
of better examples..
On the reality side, most modern operating systems
today use virtual memory and isolate each application
(i.e., "process") within its own virtual space. E.g.,
address 0x1000 translates to a different piece of real
memory for each application. The system crashes only
when it runs out of paging space on the harddrive. Then
it's a problem of simply running too many processes at
the same time. It's not the fault of the application,
but the users that loaded too many applications on
the same box at the same time.
I program on financial transaction processing devices,
most of which have no memory protection and no hard drive
(they have static ram). You are lucky if you get a
stack and 32-bit pointers :)

It's far more reliable to allocate all memory at compile-time
(ie. a fixed-size stack, and no malloc calls). You can inspect
your code to ensure that the stack will never overflow.

That only moves the fragmentation from malloc()
to stackframe management. Stackframe memory and

Stack memory does not get fragmented.
malloc() memory come from the same place. The
stack frame is fixed-size, but the compiler cannot
determine how much memory is needed for all stack
frames (recursive calls, function pointer calls).
Which is why you avoid recursion and function pointers
(unless you are being exceptionally careful). It's possible
to plot (as a human, I mean) all possible function call
paths and make sure you have a lot more stack than the
longest path will take.
Most real world problems are solved much more
efficiently with malloc() memory than swagging
a giant array on the stackframe. Load up too
many of those kinds of programs and you have
the same problems as too many malloc()-style
programs running at the same time.

Not at all; they each get their own fixed-size
stack allocated at compile-time and cannot
interfere with each other's memory allocation.

[Chris Torek]

In article <news:84**************************@posting.google. com>
Old Wolf <ol*****@inspire.net.nz> writes (in part):

Stack memory does not get fragmented.
Not in typical C implementations, anyway. There are other languages
with features like "continuation passing" that do actually wind up
with fragmented stacks, and there is nothing saying a C implementation
has to use a clean, simple, non-fragmenting stack, so a hypothetical
Evil C (Deathstation?) compiler could make a mess of it. (But note
that continuations and closures are also often implemented without
using the "hardware provided" stack anyway.)
[On particular systems,] It's possible
to plot (as a human, I mean) all possible function call
paths and make sure you have a lot more stack than the
longest path will take.

Until the next release of the compiler, anyway. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Chris Torek wrote:

Old Wolf <ol*****@inspire.net.nz> writes (in part):

Stack memory does not get fragmented.

Not in typical C implementations, anyway. There are other languages
with features like "continuation passing" that do actually wind up
with fragmented stacks, and there is nothing saying a C implementation
has to use a clean, simple, non-fragmenting stack, so a hypothetical
Evil C (Deathstation?) compiler could make a mess of it. (But note
that continuations and closures are also often implemented without
using the "hardware provided" stack anyway.)

[On particular systems,] It's possible
to plot (as a human, I mean) all possible function call
paths and make sure you have a lot more stack than the
longest path will take.

Until the next release of the compiler, anyway. :-)

Barring recursion.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!