Path: utzoo!utgpu!jarvis.csri.toronto.edu!white.toronto.edu!ghfeil
Newsgroups: comp.realtime
From: ghfeil@white.toronto.edu (Georg Feil)
Subject: Re: Memory management under VxWorks
Message-ID: <1990Feb23.124249.2957@jarvis.csri.toronto.edu>
Keywords: VxWorks, memory fragmentation, programmer frustration
Organization: /usr/lib/news/organization
References: <8136@pt.cs.cmu.edu>
Date: 23 Feb 90 17:42:49 GMT
Lines: 23

Although I'm not a VxWorks user (soon...), I often use a 'secondary'
memory allocator in conjunction with malloc(). The secondary allocator
is very simple and works only with fixed-size memory blocks, so it is fast.
It requests memory from malloc() in fairly large chunks (say 4K). I find 
that most data structures I use require only a single size of memory block 
(e.g.  the size of each entry in a linked list), or it is not too hard to
impose this restriction. Different data structures use different size blocks,
but in each case the secondary allocator only ends up calling malloc() for 
the 'large' memory chunks.  This means less fragmentation and better 
performance all around. 

This won't help in cases where the OS itself calls malloc(), but can eliminate
or reduce the problem for user code. I have C++ code for the secondary
allocator if anyone is interested (it wouldn't be hard to convert to 
regular C). It should also be easy to write from scratch.

Georg.
--
Georg Feil                                 Internet: ghfeil@white.toronto.edu
                                             -or-  : georg@sgl.ists.ca
..if all else fails, try:
{uunet,pyramid,watmath,utzoo}!utcsri!white!ghfeil      (UUCP)
ghfeil%white.toronto.edu@relay.cs.net                  (ARPA)