Article View: comp.sys.transputer
Article #1735Re: Dynamic Memory Allocation
From: Roger Peel
Date: Fri, 20 Nov 1992 17:50
Date: Fri, 20 Nov 1992 17:50
43 lines
2683 bytes
2683 bytes
Andy Newman (andy@research.canon.oz.au) wrote recently about his
involvement with a project that developed a Dynamic Memory Allocator.
I liked his account of the memory allocation procedure - and his honesty
about its non-adherence to the occam usage checking rules!
I have one comment to add. The parallel process in the middle (the
allocator process) can very easily become the performance bottleneck of
the whole of the rest of the system, since it queues up requests and
responds to them serially.
Apart from the problem of distributing permissions to access memory blocks
of varying sizes, one might consider implementing such an allocator with a
little extra buffering. This would have the effect of eagerly outputting
(in parallel) a permission token to each process that it serves. Only
when a process accepts its token does the allocator reschedule and send it
another one. Returned tokens are processed along a different set of
channels which are quite separate from the first set. Think of the
allocator and the client processes as each being separated in both
directions by small FIFOs, and notice the reduced latency that this
provides. Obviously, more tokens will be in transit at any time, and the
scheme will use its memory pool less effectively - but the benefit could
be that the system runs rather faster.
A similar benefit could be gained when implementing the TCP/IP
communications protocol, if one has also decided to use the 'mbuf' memory
allocation scheme suggested in its specification. In this case, and under
heavy network loads, the allocator will be very busy and the overhead
could be quite noticeable. Of course, this shared memory model might not
be the best choice these days, anyway!
Roger M.A. Peel
Department of Electronic and Phone : +44 483 509284 (0483 from UK)
Electrical Engineering Fax : +44 483 34139
University of Surrey Telex : 859331
Guildford JANET : R.Peel@uk.ac.surrey.ee
Surrey GU2 5XH UUCP : ...mcsun!ukc!ee.surrey.ac.uk!R.Peel
United Kingdom
--
Roger Peel
Technical Details
Message-ID:
<1992Nov20.175020.25307@EE.Surrey.Ac.UK>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!uos-ee!ee.surrey.ac.uk!R.PeelReferences:
<1992Nov11.033835.21118@netcom.com> <2225@eagle.ukc.ac.uk> <dbc.722086651@bill> <BxyB6I.LLF@research.canon.oz.au>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!uknet!uos-ee!ee.surrey.ac.uk!R.Peel From: R.Peel@ee.surrey.ac.uk (Roger Peel) Newsgroups: comp.sys.transputer Subject: Re: Dynamic Memory Allocation Keywords: Occam3 recursive Message-ID: <1992Nov20.175020.25307@EE.Surrey.Ac.UK> Date: 20 Nov 92 17:50:20 GMT References: <1992Nov11.033835.21118@netcom.com> <2225@eagle.ukc.ac.uk> <dbc.722086651@bill> <BxyB6I.LLF@research.canon.oz.au> Sender: ees1rp@ee.surrey.ac.uk (Roger Peel) Organization: University of Surrey, Guildford, Surrey, UK. GU2 5XH Lines: 43