Rhapsody memory,was Re: Memory on the Mac

Melissa O'Neill oneill@cs.sfu.ca
Sun, 12 Apr 1998 13:31:23 -0700 (PDT)


Adrian Hey writes:
> Is UNIX memory handling excellent? I have never programmed for the UNIX
> environment. But from my experiences of using UNIX apps on workstations
> I can't say I'd noticed much excellence. They seemed pretty slow and clunky,
> and they crashed a lot. But, perhaps I was using the wrong software on the
> wrong platform running the wrong UNIX dialect. Buggy apps may crash, but
> if they bring down the whole OS that does not indicate excellent memory
> management to me. (Mind you, even my beloved RiscOS is far from perfect
> in this respect.)

It's very rare for a buggy application to bring down Unix machines.
With regard to memory, it's certainly true that if an application
allocates memory stupidly and without consideration for other programs
running on the same machine, there is only a limited amount the
operating system can do, but on the other hand, a good operating
system can offer a number of useful tools and features for programs
that want to use memory wisely.

Rhapsody is based on NEXTSTEP, which uses a Mach kernel for managing
memory. The important thing is that, unlike MacOS, applications are
free to request more memory as they need it and free it up later.
They can even tell the operating system that memory isn't going to
be used in a while. Under Mach, that is achived by using vm_allocate,
vm_deallocate, vm_deactivate, and vm_set_policy -- you can even ask
about the state of memory as a whole with vm_statisics. Under a
traditional Unix like Solaris, applications use sbrk to increase or
decrease their memory allotment, and can tell the operating system
about their paging behaviour using madvise.

The way SML/NJ handles allocating memory is that it allocates a chunk
initially, and then at each garbage collection, it notes how full that
memory is. If it's getting full, it allocates some more (contiguous to
the memory it already had, of course), because it looks like the task
will need it. (Similarly, if it does a garbage collection and there is
lots of garbage, it frees up some of the memory).

I imagine that other garbage collected languages that are well behaved
on multiprocessing machines do something similar.

> One thing still puzzles me though. If Rhapsody is really just UNIX with
> knobs on, then there shouldn't be any great difficulty in porting Clean
> to it. Most of the necessary compiler features (relevant CPU's supported)
> and libraries for UNIX (Linux/Sun OS/Solaris) already seem to be there
> (albeit still version 0.8). But, as usual, I'm probably overlooking
> something. Perhaps the most of the libraries need re-writing due to
> GUI differences.

Unixes are differ in how they do some things. Most things work the
same, but there are a myriad of little differences that need to be
taken acount of. As we saw above, the low level (kernel) calls for
allocating memory are different (but at the ANSI C level of malloc and
free, they're the same, though). So, it's not just the outer GUI
matters that need addressing, it's a lot of little things. Porting
from one Unix to another is usually tiresome, rather than difficult.

Hope this helps,

    Melissa.

P.S. Yes, most applications I've seen on Solaris are terrible. To get
an idea of what to expect from Rhapsody, go look at a NEXTSTEP machine.