🚀 go-pugleaf

In article <nevin-2309950352130001@mac-nevin.cs.arizona.edu>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <43qh32INN3hl@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
>(Kazimir Kylheku) wrote:
>
>> My argument was that simple malloc-like heap management is more than
>> sufficient to manage the dynamic data space of most applications, and that
>> handle schemes are ridiculous overkill.
>
>And this is based on what exactly?  Proof otherwise:  the Mac only does
>compaction (and purging) if there is not a large enough free block to
>satisfy an allocation request (coalaesing is done on freeing the block). 

Of course, that goes without saying.

>Many applications have had their heaps compacted in the past.  Therefore,
>it is not overkill.  The only alternate strategies I've seen you post is

I'm not saying that the compaction never happens or that it doesn't
squeeze out extra memory. I'm just saying that it's not worth the trouble.

>to either just quit the app, or throw a heck of a lot more hardware (RAM,
>disk space, etc.) to delay the problem.  Have you even bothered to read

I didn't post that at all. Someone else made the claim that virtual
memory somehow solves the problems of fragmentation. I believe that if
things get so bad that the heap has to be compacted, you are getting close
to running out of memory. Something is going to have to quit.

My solution is to block allocation requests that can't be satisifed, or
raise some sort of exception when an allocation request fails so that
the process can take action, such as inform the user that memory is
low and then restart the request.

>Inside Mac to try and understand why Apple implemented memory management
>in this way?

Oh, I see. The Mac is special, so we need Mac-specific computer science
literature.

>> A lot of old Mac programs (especially shareware) won't run on modern Macs,
>> but ghosts of the original design still plague the system.
>
>I have a copy of Missle Command from 1984 that still runs.  The main
>problem with old apps is that they *knew* how the memory manager locked
>handles and did it directly instead of calling the system.  At no point
>did I have to throw away every single piece of software that I had and
>start over; I got to do it gradually, which is something my pocketbook
>could handle, as I am not as rich as you must be to support the kinds of
>solutions you keep proposing.

I'm not rich at all. You must be rich if you can afford to replace
your programs as the OS gods change their whims. You know very well that
today's Mac computers have all the hardware features needed to support
sophisticated operating systems. I think that it is you who must be
rich to waste hardware like that.

>> You mean they don't suffer from external fragmentation.  The internal
>> fragmentation is there, but it's simply not a problem. You don't feel it.
>
>The only way you don't feel it is if you spend enough money to delay the
>problem.

If you are truly running out of memory, you don't have any choice. Heap
compaction only temporarily forestalls running out of memory.

The Mac's broken virtual memory scheme doesn't allow you to efficiently
use cheap disk space as extra memory. You have to get the RAM to make
a Mac work well. The OS itself is more bloated than Solaris and does far less!
I posted a message recently about how a 7100 with 16MB of RAM was
quite unresponsive when I was editing a small image using Photoshop,
and running no other apps and no extensions. I was told by respondents
that I should have used more RAM.

IMHO, 16MB of RAM should be more than enough to run an operating system
and edit a 600x400 image! I think that it's Mac users who must be rich
to afford to buy enough RAM to satisfy peak usage instead of settling for
cheap disk space. (Could you set up MacOS with a 64MB swap space against
16MB real RAM? I'm talking about demand-paging with LRU page replacement,
not some RamDoubler gimmick). You have to be rich to run emulated
68K code on a RISC machine. Wish I could burn cycles like that.

>> They have problems, but from my experience with Amigas, I have found
>> them to be quite stable compared to the Macintoshes.
>
>I find them just as stable/unstable as Macs.

So why does the Mac OS go through all the fuss? I've used Amigas, and
never had the slightest notion that some memory ought to be moved around
to make the machine work better. The systems worked hard given the
resources they were endowed with.

>> It could have something
>> to do with not contorting the act of programming around some asinine
>> memory allocation scheme.

>Well, since you don't believe that compaction helps, there is nothing
>stopping you from keeping the handles locked all the time.  Also, most of
>your code probably isn't doing system calls, so it shouldn't need to
>change much (they can still use pointers).  There is even a handy NewPtr()
>call, and most of the development environments implement malloc() for you.

But don't these methods defeat the compaction efforts? If you are going to
start locking handles all over the place, you might as well not have 
any compaction. 

>Another benefit to handles is it makes it easy to grow the size of the
>allocated block.  This is hard to do with just pointers, as one has to do
>a lot of bookkeeping in case more that one pointer is pointing to the same
>block.  I can have as many copies of the handle as I want and not have to
>worry about this.

It's not hard to do with pointers at all. Your variable-sized data will
almost always be referenced from a header record; the other references
will go to the header record, not to the actual variable data block.
I've never seen code that tries to maintain and update multiple pointers
that reference data that gets realloc'ed. E.g., you could have something like


	struct image {
		int width, height;
		char *data;		/* 8 bit grayscale	*/
	};

where you can change the size of the image data to reflect a changing
width and height.  Multiple references to the image point to the
structure, not to the data directly.  To do this with handles, you would
have to have a handle for the image data structure (one level of
indirection just to get to that), then a second handle for the variable
data.  You would follow the handle (indirect indexed dereference), then
chase the pointer to the structure (another indirect indexed
dereference) to obtain the handle of the data, do a third dereference to
get to the actual data pointer followed by a fourth dereference to get
to the data.  That's three levels of indirection instead of one.
Presumably, the handle dereferences are hidden behind wrapper functions
to hide the implementation of handles from the programmer, but
even if they aren't, the performance hit and increase in code complexity
is atrocious. 

Tell me again how much easier handles are supposed to be? While you
are at it, expound on the virtues of the superior Macintosh multitasking
model.
-- 
PGP key id is 0xD3C7995D.
Molybdenum 95! Got your ounce of fission byproduct yet?