🚀 go-pugleaf

Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
: In article <MLM.95Sep20011239@monaco.cs.brown.edu>,
: Moises Lejter <mlm@cs.brown.edu> wrote:
: >In article <43nlc8$sll@orion.cybercom.net>, jerry@cybercom.net (Jerry Shekhel) writes:
: >
: >  Jerry> UNIX systems ignore the problem and let the applications
: >  Jerry> worry about their own heap management.  The OS itself
: >  Jerry> provides only rudimentary facilities for expanding the heap.
: >  Jerry> On the other hand, UNIX provides very robust virtual memory
: >  Jerry> capabilities, so most programs can get by using only the
: >  Jerry> unsophisticated heap management of malloc() and related
: >  Jerry> functions.
: >
: >I am not sure how fair this statement is to modern versions of UNIX.
: >It is true that the OS itself provides rudimentary facilities for
: >expanding the heap - just sbrk() to extend heap memory.  However, the
: >standard C library's heap allocation routines (malloc() and friends)
: >do try to do a reasonable job in terms or reusing freed blocks,
: >compacting contiguous free blocks when convenient.  I will grant you

: Yup. Even the implementation of malloc() given in the K&R book is
: sufficient for most needs (though it doesn't use very efficient
: ways for searching for bree blocks). It's far better than some
: contorted scheme involving double indirection.

You are forgetting that the Mac only did the compaction when the other 
methods failed. If there was enough contiguous memory to fill your request, 
you could have it, it was only when there was enough memory, but not in a 
single chunk that it moved stuff around.
 
BTW: The Mac (and Apple // GS) did have virtual memory but it was 
implemented by the programs and the OS, in co-operation. The program 
would set permissions on a block of memory and if it or another process 
(TSR type stuff) requested an ammount of memory it would look for a 
suitable chunk, failing that it would analyze the usefullness of 
compacting (before it actually did anything), then if there wouldn't be 
enough it would swap out static blocks (ie code, things that didn't 
change) in the order (determined by the programs) of least to most important.

The idea being that the only thing that needed to be left in memory was a 
small 'event manager' with capability to ask that sections of code would 
be loaded, and the data it was working on. This wasn't optimal, but if 
you used fairly well written apps (and they put more care into it then, 
when they had to) you could have a lot more things going at once that you 
had ram to use.
 
The derefrencing a pointer (pointer to a handle to a block of memory) 
wasn't a big deal because each time you go to do something, you call the 
OS and lock it down (very quick, just ANDing a bit in or out) then run 
your routine, then unlock before the end... It's not something that had 
to be done before each read or write.

: >it is possible to construct an application whose dynamic memory
: >behavior will defeat the strategies in the standard C library, but I
: >am not sure that this is commonly a problem...

: Could you cite a reference as to where to find an example of such
: an allocation pattern?

No, but I can describe one easily!

Imagine you have a routine that loads 100k of data, operates on it, 
stores a 1k result, etc...
 
You load few chunks of data, operate on the last, dealloc it and store 
the result... it goes in the 1st k of the now empty 100k..
 
Operate on the next chunk, dealloc it and store the results, etc...
 
Now you have a bunch of ram with 1k used then 99k free... Lotsa free ram 
unless you need to load something 100k or larger.
 
Yes, this is lousy style, but it happens... The routine or the OS need to 
be able to handle it, or you have to pass it off to the programmers, and 
this is what we are getting away from these days. We are supposed to be 
able to assume that if the machine has 16megs, then we can allocate at 
least 16megs - OS space + Virtual memory without having to do anything 
stupid (like Dos Extenders etc... ick.)

: I suspect that in the long run it would be easier to fix an application's
: allocation pattern, should the need arise, than to force yourself to
: complicate _every_ application with nonsense like memory handles and
: double dereferencing.

What if you have two applications both using system memory in a dynamic 
way, then it's real easy to imagine ways for things to become fragmented. 
Should we only use non-multitasking systems because of this? Without 
interrupts (because these could alloc memory of their own)... If we are 
assuming a machine without hardware virtual memory (and that's what the 
early Mac and Apple // GS were) then that's the only option that doesn't 
end up with something as screwed up as MS-DOS.

: I think the original Mac designers should have stuck to pixel pushing,
: and hired outside help to do the internals. I suspect that the 
: NIH (Not Invented Here) syndrome had a lot to do with it.

Could you have done better?
 
Can you even now come up with a better (more flexible and functional) 
SOFTWARE solution?