🚀 go-pugleaf

In article <43d484INNlge@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

> One thing that's "good" about PMT that's often overlooked is that it
> doesn't allow the programmer to make assumptions about whether real
> or apparent concurrency is going on. You have to use synchronization
> mechanisms which scale well to multi-processors.  The way cooperative
> multitasking is done on the Mac is particulary bad, because it is
> based on ad-hoc methods.

Er, the original MacOS was never, never designed to run on multiple CPUs. 
It was designed for a machine with no MMU, no hard drive, 64K of ROM, 128K
of RAM, run fairly fast, concentrate on teh interface, and only run one
app at a time; in other words, affordable hardware in the early 1980s. 
After that, keeping the OS backwards compatible was a major goal (and a
very necessary one from a business standpoint).

> Here is where the stupidity comes in: the system
> re-arranges the allocated blocks in order to defragment the free space,
> by physically pushing their contents around memory. If you store pointer
> references to data within a block that has been moved, they will no longer
> be valid.

Unless, of course, you lock down the handle.

> The reason this scheme can work is because of the "cooperative"
> multitasking.

> You see, as long as you don't give up the CPU, memory will
> not be moved on you. After your program returns from an explicit "yield"
> call, it has to take steps to ensure that all accesses to global blocks
> go to the right places, by dereferencing the right handles. Not only
> is the CPU not virtualized, but neither is storage. 

Given you were designing the Mac in the early 80s with the above
constraints, how would you have done it?  Only a Pinhead would virtualize
CPUs on a machine designed only to run one app at a time.

> The Mac system programmers should have read the volumes of The Art of
> Computer Programming by Donald Knuth, in particular the sections on heap
> management where it is argued that it's better to coalesce adjacent free
> blocks into larger blocks than to try to do garbage collection.

And what happens when your 128K of RAM is totally fragmented??  Your way
is shit out of luck, reboot.  The Macs way is do some garbage collection
and continue on.  Have you ever even bothered to map out typical
allocations in a Mac application to see if Knuth's reasoning is
applicable?  Of course it's better (in terms of run-time efficiency) to
coalesce adjacent free blocks, but in a typical windowing-based or
object-based system that has lots of heap allocations, it just doesn't buy
you very much in terms of the amount of memory you get back (actually, it
still gets done anyway, because it doesn't cost very much to do).  What is
your solution to keeping the application and the machine running when this
doesn't give you a big enough chunk of memory back, and you don't have an
MMU and a hard drive to play VM tricks with to delay this problem?

> I
> suspect that the programmers probably had experience implementing
> BASIC interpreters (kind of like Billy Gates), and applied similar
> strategies to OS programming. ("Let's do garbage collection like old
> Applesoft BASIC did on strings!")

And why did they do garbage collection on strings in the first place? 
Because the heap strings are allocated out of tends to get fairly
fragmented, and memory in those days was a very, very limited resource. 
This was still true when the Mac came out, and for a number of years after
that.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799