Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!Teknowledge.COM!unix!garth!fouts@bozeman.bozeman.ingr.UUCP (Martin Fouts)
From: fouts@bozeman.bozeman.ingr.UUCP (Martin Fouts)
Newsgroups: comp.unix.cray
Subject: Re: Malloc() under UNICOS
Message-ID: <729@garth.UUCP>
Date: 10 Sep 90 16:31:42 GMT
References: <5931@castle.ed.ac.uk> <61360@lanl.gov>
Sender: fouts@garth.UUCP
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 49
In-reply-to: ttw@lanl.gov's message of 28 Aug 90 16:51:52 GMT

>>>>> On 28 Aug 90 16:51:52 GMT, ttw@lanl.gov (Tony Warnock) said:

Tony>      Generally, system actions such as MALLOC() cannot be speeded up.
Tony>      These ususally require at least a trip through the operating
Tony>      system. If the current location of the program in memory does not
Tony>      have enough room for the program to expand, the job must be swapped
Tony>      to disk and then put back into a larger slot.

Malloc is not strictly a system operation, and doesn't always require
a trip through the operating system.  The underlying system call is
brk/sbrk, which adds memory to (subtracts memory from) the end of the
data section of the program's address space.  malloc/free/realloc
manage that memory once it has been allocated.

Malloc manages the pool of memory which has been allocated by the os.
When more memory is requested, malloc tries to find it from a pool
already in your address space.  If it can't find the free memory
within the address space it makes the system call to acquire more.
When free is called the memory is reallocated to the free pool.  The
system call to shrink the size of your application is not usually called.

Tony>      The only good way to remove time from MALLOC() is not to call it
Tony>      as often. You will have to re-write your algorithm not to do
Tony>      so much memory management.

There are two other ways.  One is to call it with larger chunks of
memory in requests, often requiring memory management modifications to
algorithms.  The other is to replace it with a variation which uses
structure imbedded in your algorithm to produce a more efficient
memory manager.

If the original programmer is only calling malloc and never calling
free or realloc, it should be fairly easy to find a faster
implementation.  (As a quick hack, the program might first malloc and
then free a huge chunk of memory -- depending on which mallocator is
currently running on your system, this will greatly reduce the number
of system calls made, but might increase the amount of time spent
swapping.)

--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa