Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ur-tut!ur-valhalla!micropen!dave
From: dave@micropen (David F. Carlson)
Newsgroups: comp.unix.xenix
Subject: malloc problems in SVr2/286 (Microport et al.)
Message-ID: <381@micropen>
Date: Tue, 29-Sep-87 10:50:57 EDT
Article-I.D.: micropen.381
Posted: Tue Sep 29 10:50:57 1987
Date-Received: Tue, 6-Oct-87 06:11:28 EDT
Organization: Micropen Direct Writing Systems, Pittsford, NY
Lines: 43
Keywords: malloc sbrk errors

I read the paper on the 286 port of SVr2 recently and have been "playing"
with malloc() recently to see how I might be able to use it with any
predictability.  (See UNIX Papers, Waite Group, Howard Sams, 1987.)

First, manuals are incorrect that one can allocate 64K - 1 bytes (a per 
segment limitation of the 286 architecture.)  First, malloc(3) uses 1K for 
internal use.  I was empirically unable to allocate more than 64476 bytes 
using Microport malloc(3), which is a mysterious 34 bytes shy of a full load 
with the 1K overhead.

Once memory is allocated, the segment is never released in a corresponding 
free(3).  Moreover, only the last allocated segment is used to fill new 
requests, and since mallocs that required new segments to be allocated ask 
for the exact amount of memory (plus 1K overhead), all new mallocs without 
intervening frees will cause a new segment allocation *per malloc*!.  
(This is only true for relatively large requests.  The minimum malloc seems 
to be 4K (including 1K overhead.)

My personal workaround (especially where many malloc/free are expected) is to
allocate a large malloc segment (with the max limit above) and then immediately
free it.  Thus, all subsequent requests will fill out of that preallocated
space rather than forcing the creation of many segments in the LDT.  (One of
my programs had over 75 segments created by small malloc requests.)  It is
"unfortunate" that the '286 malloc(3) cannot ever recover memory once its been
allocated.  An extra level of indirection in the malloc allocation routine
and a working sbrk(2) would allow a full featured malloc(3).  My workaround
above doesn't actually help free(3) free the segment, but most small requests
can be satisfied out of the 63K segment, since upon subsequest free(3), space
can be realloced whereas if several small segments are allocated by small malloc
requests before a free(3), those blocks will never be reallocated as only the 
most current segment is used.  Thus, the buried segments may add up quickly if 
many small (1K) malloc/free sequences are performed.

Although tested under Microport, I believe these some of these problems are
endemic to '286 segmentation arrangement and most to not wanting to spend
the effort to "fix" malloc(3) and sbrk(2).  Results are untested under any
flavor of Xenix.

-- 
David F. Carlson, Micropen, Inc.
...!{seismo}!rochester!ur-valhalla!micropen!dave

"The faster I go, the behinder I get." --Lewis Carroll