Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ur-tut!ur-valhalla!micropen!dave
From: dave@micropen (David F. Carlson)
Newsgroups: comp.unix.microport
Subject: Re: Info needed: UNIX for 286/386 machines (really malloc)
Message-ID: <428@micropen>
Date: 15 Mar 88 15:24:17 GMT
References: <427@micropen> <777@nuchat.UUCP>
Organization: Micropen Dirent Writing Systems, Pittsford, NY
Lines: 31
Summary: malloc is the easy part

In article <777@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
> Re: flamage about the 286 malloc.
> 
> It really is a crock.  I looked into it and wrote the following
> allocator in support of pathalias, and it works with good
> efficiency (both space and time).
> 
> If someone wants to layer the free() logic, say from K&R,
> on top of this it would make a very usable replacement.
> 

Malloc itself is easy as the code Steve has written illustrates.
Note this implementation is fixed in the maximum allocated space.
Also free is not so easy as he would have us believe:  free must
allow future mallocs to look at all the freed space for allocation
of potentially large spaces.  If this infomation is stored in the
local segment, how many objects can be allocated in toto?  If this
information is stored globally, then a very hard limit of total objects
storable is made.  I have never had any trouble with Microports malloc,
but rather malloc-free-malloc combinations which cause unbounded process
growth.  This problem is not without solution but any varients I've 
thought of imply expensive tradeoffs in time/space for the generic
malloc I've come to know and love on linear addressing machines.



-- 
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave

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