Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!agate!bionet!csd4.milw.wisc.edu!uwmcsd1!marque!uunet!mcvax!unido!tub!uwbln!ckl
From: ckl@uwbln.UUCP (Christoph Kuenkel)
Newsgroups: comp.unix.wizards
Subject: Re: System V.2 and growing processes
Message-ID: <1289@uwbull.uwbln.UUCP>
Date: 9 Jan 89 14:44:01 GMT
References: <627@cimcor.mn.org> <8680@alice.UUCP> <10746@rpp386.Dallas.TX.US>
Distribution: comp
Organization: UniWare GmbH, Berlin
Lines: 29

In article <10746@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
> Well, now you know ;-)  Had a realloc been added these problems wouldn't
> exist.  I had added a realloc() which tested for adjacency and it resolved
> this problem partially.  The conclusion I reached was that processes
> should allocate physical memory in large chunks and then manage the
> unused space, rather than growing one click at a time.
> 
My solution is to estimate the maximum size of dynamic memory a process will
need and code something like:

    ...
    register char *p;

    p = malloc(ESTIMATED_SIZE);			/* 1. */
    (void) malloc(1);				/* 2. */
    free(p);

Step 1 is to grow the process with a single swap out/swap in, step 2 is
to avoid shrinking of the process's break value.

Seems to work quite fine.  Is it much more stupid than I realize?
(Yes, I dont use the maximum size for long-running programs with extensively
varying memory usage)

christoph
-- 
# include <std/disclaimer.h>
Christoph Kuenkel/UniWare GmbH       Kantstr. 152, 1000 Berlin 12, West Germany
ck@tub.BITNET                ckl@uwbln             {unido,tmpmbx,tub}!uwbln!ckl