Rhapsody memory,was Re: Memory on the Mac

Adrian Hey ahey@iee.org
Sat, 11 Apr 1998 20:30:35 +0100 (BST)


On Fri 10 Apr, Brent Knight wrote:
> In Apple Computer's Rhapsody Blue Box, applications always get a heap of 
> the size they specify in their SIZE resource and never have to settle for 
> less memory.  And since this memory is virtual, application-writers and 
> users can set this number as high as they need to without worrying that 
> they will consume scarce physical memory and prevent other applications 
> from launching.  Although it is not as pure as some people might hope 
> for, this is a very practical solution that should satisfy most people.  
> Keep your eye on Allegro, too.

At the risk of being diverted to much from the main topic of this
discussion list (we're supposed to be discussing Clean), I have a
few concerns about the Rhapsody Memory management scheme as described
above. I only mention them here because they are potential problems
for all applications which use a garbage collected heap, including
Clean programs (asuming Clean will be ported to Rhapsody at some time).
Furthermore, since such applications are likely to be increasingly common
in the future, these problems are likely to become problems for the
Rhapsody OS.

I won't start by saying 'you can't do this' or 'that won't work',
because I don't no enough about how Rhapsody is really going to manage
memory to be that specific. Instead I will just make a few observations
and see what anybody else has to say.

Perhaps someone from the Clean team could comment. Perhaps someone at Apple
could stop to think about this, if they haven't already and if it isn't too
late.

Observation 1
-------------
Any memory management system that relies on users fiddling about with the
size of applications workspace is far from ideal. (I am tempted to say
totally unacceptable, but of course if this is what Apple do then users
will have no choice but to accept it.) How many users even know what a
'mega byte' is, let alone how many are likely to be needed?
Even the applications authors can't determine this with any confidence.

Wouldn't it be better to reserve this for feature for 'pre-historic'
applications and encourage new applications to cope with one
(or more) dynamically sizeable (but contiguous) workspace(s).
Of course this requires some kind of hardware mapping from logical
addresses and physical addresses, but since Rhapsody is using
virtual memory anyway I take it this isn't a problem.

Observation 2
-------------
At this point I can imagine some people will be asking thamselves why
bother with all that when you can just set an applications workspace
to some ridiculously large value. If all that RAM isn't really there then
virtual memory will sort it all out for us. Well, maybe, but consider this..

Although there are a number of heap management and garbage collection
schemes available, most of them work by consuming the entire heap
space and then performing garbage collection, usually followed by a
compaction phase to free up heap space as a contiguous block.
As a result most such schemes benefit considerably if there is much more
heap space available than the heap actually occupies, since garbage
collection becomes less frequent. But this is ONLY true if the entire
heap space is in RAM. Since heaps (containing 'structured' data,
pointers etc..) really do need to be random access, there will be horrible
performance penalties if page swapping kicks in. I can see the hard disk
getting a very severe thrashing. If the heap space that the application
sees is much larger than the actual amount of RAM available (as I suggested
above) then this will inevitably occur.

The only realistic way of stopping this happening would be to ensure that
the heap space that an application sees is reasonable, given the total
amount of RAM in the machine and assuming that virtual memory would
enable the application to monopolise most of the RAM when it was
active. But can you trust users to get this right? Wouldn't it be better
if the application and OS could negotiate between themselves so that the
applications needs were met (as far as is possible) without compromising
the overall system performance too much, and without the user needing to
know or understand what was happening?

Observation 3
-------------
There are inevitably performance penalties to be paid when virtual
memory is used. (I suppose I should say when memory pages a swapped
between RAM and disk, which only happens if the ammount of logical memory
used exceeds the machines RAM.) I would think that some scheme which
minimised the amount of logical memory used would pay handsome performance
dividends. After all, most of the time applications will need a lot less
memory than they do in the worst case scenario. But it is difficult to see
how to take advantage of this fact unless applications workspace(s) can
be dynamically adjusted. I.E. The application can ask the OS for a workspace
to be increased and, just as important, the OS can ask the application for
some workspace back. I think this is especially important with garbage
collected heaps for the reasons indicated earlier. The apparent
wastefulness of garbage collected heaps (heap space much larger
than the heap) could be fixed by performing a garbage collection
in response to a 'give me my RAM back' request from the OS.
I suspect that this would be considerably faster than swapping heap
pages to hard disc (especially when you consider that an awful lot of those
pages would be garbage anyway and time spent garbage collecting isn't
entirely wasted, the application gets a payback later).

Observation 4
-------------
Some kinds of block structured data suffer less as a result of the use
of virtual memory. This is why I suggested that an application might
have more than one workspace. For example you could put all the stuff
that really did need random access in one area and all the stuff that
required sequential (or repeated localised) access in another. In this
case the second area could be targeted for page swapping in preference
to the first.

Observation 5 :-)
-----------------
A few hours of listening to a hard drive clattering away gives me an 
awful headache. Thats why a hate PC's. Mac's are a lot better in this
respect. But my RiscPC is absolutely silent, NO virtual memory, very
efficient use of RAM, dynamic areas, ultra fast, and I haven't run out
of memory yet (ever). It would be nice if Rhapsody could be as quiet as
RiscOS already is, but it doesn't seem likely. The mere fact that
virtual memory is available is likely to result in criminal RAM wasting,
which will in turn make virtual memory absolutely necessary. The quote
at the top of this message practically says as much. If you need any
more convincing, look at what's happened to PC's. In the good old
days of DOS they were cr*p, but reasonably fast (given the technology
of the day). Nowadays they're not quite as cr*p, but appalingly slow
(given the technology of today). Could Rhapsody be heading the same way?
I shall watch future developments with a very smug expression on my face.

But seriously...

Like it or not, RAM IS a scarce resource and should be managed with care.
After all, if this weren't true, why bother garbage collecting at all?
I don't know to what extent the ideas here are compatible with what
Rhapsody is really going to do (and maybe they're not such good ideas
anyway !!??). I suppose it all needs thinking through pretty carefully.
Perhaps the Rhapsody scheme is really a lot more sophisticated than it
appears. But it seems to me that the assertion that programmers and
compiler writers needn't worry about memory any more, because the virtual
memory fairies will sort it all out at run time, is just wishful thinking.

Any comments?
Have I missed something here?
Am I being stupid?

Btw, does anyone know what Allegro is and why we should keep our eye on it?
(Sorry, but as a general rule I'm not the least bit interested in what's
happening in the Mac/Apple world, hence my ignorance. I suppose this
situation might change if I thought there was some prospect of getting an
OS I could believe in.)

Regards
-- 
Adrian Hey