Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!amdahl!ems!pwcs!stag!daemon
From: to_stdnet@stag.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: malloc bugs (s.b. Malloc bugs)
Message-ID: <575@stag.UUCP>
Date: 29 Aug 88 19:15:04 GMT
Sender: daemon@stag.UUCP
Lines: 75

From: dal@syntel.UUCP (Dale Schumacher)

[leo@philmds.UUCP (Leo de Wit) writes...]
> In article <4120005@wdl1.UUCP> dinolt@wdl1.UUCP (George W. Dinolt) writes:
>     [amongst other things]...
>>In fact the MWC compiler has an lmalloc(lsize) which takes a long as an
>>argument, so in that compiler at least, there is no need to use Malloc.
> 
> It depends on where this lmalloc does its allocation. In Lattice C
> malloc also takes a long as argument (an int being 32 bits in
> Lattice).  Because the heap is lying between bss and stack the
> available space for this malloc depends on what is allocated for the
> program at startup time (by Mshrink); for instance a 'sh', a 'make', a
> 'find', a 'time' do have to leave room for other programs to exec in.
> Then it can be profitable for a program to use both the system Malloc
> and the C library's malloc.

This is one problem with malloc()ing from a fixed heap area in the middle
of the program's memory space.  For those who aren't familiar with it, this
is a rough picture of a running C program's memory map.

	low memory
		 _______________________________  base
		|basepage (a.k.a. the TPA)	|
		|-------------------------------|
		|text (executable code)		|
		|-------------------------------|
		|data (initialized data)	|
		|-------------------------------|
		|bss (uninitialized data, zero)	|
		|-------------------------------| break
		|heap   |			|
		|	V			|
		|		:		|
		|	^			|
		|stack	|			|
		|_______________________________| end of program space

	high memory

The stack grows toward the heap, and the heap is usually allocated by calls
to malloc().  This means Malloc() is not used for dynamically allocated
space within the program.  One problem with this scheme is that the program
must know at startup how much space it will need for it's heap.  Also, any
space reserved for heap cannot be used by other programs executed from
within this program.  And finally, there may be PLENTY of free memory still
available in the system (throuh Malloc()), but when you're out of heap,
you're out of memory.

> I could however imagine a malloc that uses Malloc to reserve memory not
> currently owned by the program... A clever one can even hide some of
> the defiencies of the current Malloc (especially when it Malloc's in
> big chunks so that it doesn't have to be clever too often, as
> cleverness takes time 8-).

The dLibs malloc()/lalloc() functions do this.  A global variable, which
defaults to 64K allows the programmer to set the "granularity" of the
calls to Malloc().  Calls to malloc()/lalloc() allocate a series of "heaps",
each at least the grain size (lalloc() may specify a block bigger than
the grain size) from which subsequent malloc()/lalloc()s are satisfied,
with only 4-bytes of overhead per memory block.  I've used these routines
in a MicroEMACS implementation (which malloc()s each line) and never had
a problem, even when adding/moving/deleting large amounts of text.  In
addition, this scheme allows almost ALL of unallocated memory to be used
by programs executing from within another program.  Allocation from the
heap is also available, through brk()/sbrk(), and another global variable
defines the size of the heap/stack area.  Best of all, the source code
for these routines is part of the public domain dLibs C runtime libraries.

--
      Dale Schumacher                         399 Beacon Ave.
      (alias: Dalnefre')                      St. Paul, MN  55104
      ...pwcs!stag!syntel!dal                 United States of America
  "Man who says, 'It cannot be done', should not interrupt man who is
   doing it." -Ancient Chinese Proverb