Info needed: UNIX for 286/386 machines (really malloc)

[Steve Nuchia]

>From article <428 at micropen>, by dave at micropen (David F. Carlson):
> In article <777 at nuchat.UUCP>, steve at nuchat.UUCP (Steve Nuchia) writes:
>> 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.

Did you read my note?  K&R provides a very simple alloc/free
algorithm, based on allocating a chain pointer/free flag
word with each piece of memory allocated.  Adding this would
be trivial and architecture independent.

Stock malloc works but is very very slow when allocating
many small pieces of memory - at least a brk() per kilobyte
or whatever the figure is.  My code is a great deal faster,
where it is applicable.

There are published algorithms for storage allocation that
beat the "malloc [we've] come to know and love" to death in
both time and space.  Microbug's -lmalloc is based on one of them.

To implement any one of them someone would have to duplicate
my effort or steal my code - figuring out how sbrk() and brk()
interract in large model was not at all fun, and I think it
was worth posting a limited routine to make that knowledge
available.

And as far as being "fixed in the maximum allocated space",
you show me a uPort 286 system that will let you allocate
65 60Kb segments and I'll eat my hat.  Well, perhaps it
is possible, since that is only four meg... but the extension
mechanism is obvious.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947