Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Message-ID: <20087@beta.UUCP>
Date: 8 Jun 88 23:23:40 GMT
References: <19730@beta.UUCP> <4332@killer.UUCP> <802@elxsi.UUCP>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 27

In article <802@elxsi.UUCP>, rw@beatnix.UUCP (Russell Williams) writes:
> [...]
> If explicit loading and unloading of data is more than hints to an MM, 
> it is another serious source of bugs.  Errors in overlay schemes result in
> wrong answers, errors in MM hints only in performance degradation.

Memory management itself causes performance degradations also.  In the
case where the entire program fits main memory, any overhead in the memory
interface due to memory management hardware is a waste.  In the case where
the MM 'hints' that you suggest using are always accurate, the memory
management overhead is also just wasted time.  Further, since most memory
management hardware doesn't allow such hints, the penalty for codes which
can accurately predict data usage is large indeed (MM often swaps out the
very data that the code is going to need soonest).

You're right that errors in software memory management can produce errors
in the result.  However, there are programming environments that do
software MM (and have done so for years) without this source of errors
becomming too burdensome.  Large scale production codes in these places
would just be penalized by adding hardware MM.  Certainly, hardware MM
without the 'hint' capacity would be totally unacceptable.

Hardware memory management is just one of many useful tools in the
designers toolbox.  It is not an appropriate tool for ALL applications.

J. Giles
Los Alamos