🚀 go-pugleaf

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

> 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.

> 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.

Do you have any measurements to back this claim up?  Again, real apps that
ran on real Macs prove otherwise.


> >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.

No.  If you read IM, you'd understand what problem they were trying to
solve with handles.  You are the one who thought that it had something to
do with multitasking, and were dead wrong about it.

You seem to know a lot of factoids, but don't seem to be able to grasp the
understanding and knowledge that should go with it.

> >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.

The point is, I don't have to do that.  Plus, I could afford to run those
apps much earlier, since they don't require as much hardware.

> I think that it is you who must be
> rich to waste hardware like that.

I'm not willing to throw away all my old software just to do so.  Most
people aren't; hence the popularity of PCs.

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

Yup.  There isn't much choice if you can't afford more.

> The OS itself is more bloated than Solaris and does far less!

That's funny; last I checked, I couldn't boot Solaris off of one floppy.

> IMHO, 16MB of RAM should be more than enough to run an operating system
> and edit a 600x400 image!

Was it truly a 600x400x72dpi image, or is that just the size of the window
you were displaying it in?  What was the bit depth?  Were you running a
native version of PhotoShop?  What were you trying to do with the image?

> Wish I could burn cycles like that.

This from a Unix user; the system that wastes cycles just to keep the
implementation of the OS and the tools simple.

> 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.

User, or programmer?  Handles are a programmers' concept.

> But don't these methods defeat the compaction efforts?

Yup.  It's a tradeoff.

> If you are going to
> start locking handles all over the place, you might as well not have 
> any compaction. 

If it simplifies your life, and if people are still willing to buy your
app even with large disk and/or RAM requirements, then there is no reason
not to do so.  For the rest of us, the more hardware our apps require, the
less customers we have for those apps.

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

And how is this better than handles?  I'd probably put the data pointer
first, as it makes the double dereference quicker.

> 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.

And how does this differ from handles?  Multiple references to the object
point to the handle, 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.

Why?  I could store it as a handle to something like:

struct image {
   long     width;   /* only Pinheads use ints in structs in portable code */
   char   data[1];   /* ANSI C won't allow data[0] or data[] */
}

since I can get the size of the handle directly from the system when I
need it, and can calculate the height directly from it given the width. 
Just store the image directly after the width.  There are tons of
variations on this.  Just because you would code this naively doesn't mean
the rest of us would.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799