System V.2 and growing processes

[Michael Grenier]

>From article <1289 at uwbull.uwbln.UUCP>, by ckl at uwbln.UUCP (Christoph Kuenkel):

  John talks about a standard UNIX System V.2 kernel which Microport
appears to use for their V/AT product (to their credit). I had asked
why the brk call always requires the entire process to swap/relocate
in memory or swap to disk.

> In article <10746 at rpp386.Dallas.TX.US>, jfh at 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)

Chris,
    Your method would work fine on a non-brain damaged CPU. My problem
however exists on an Intel 80286 processor where one can only malloc
or increase the break value by one segment at a time or less than
64K bytes at a time. Thus if I know the process is going to consume
1 megabyte of RAM, the process has to allocate 1M/64K or at least
16 times. Each time I allocate a block, the process swaps more slowly
which is very fustrating when its obvious that the memory is available.

Moreover, the 80286 processor wouldn't even need that memory to be
contigous to the given process since its virtual memory via selectors
will map the process addresses to various segments throughout physical
RAM. 

John's method of adding a realloc call within the kernel is probably
a good idea on a 80286 if reasonably fast brk/sbrk/mallocs are going to
be achieved for user processes. Hopefully, Microport can look
into this problem.

    -Mike Grenier
	mike at cimcor.mn.org
       uunet!rosevax!cimcor!mike