Re: Confusion
Re: Confusion
- Subject: Re: Confusion
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 25 Jun 2001 09:00:14 -0400
And it is one of the primary contributors to classic Mac OS's
instability as well as the primary reason why MacOS never had-- couldn't
have-- a real virtual memory model. The core reason, of course, is
that MacOS used unprotected memory.
Every process effectively ran in a single huge memory space and every
process had write access to all of the memory space. Because every
piece of memory had to be addressable from the context of every single
application, this makes it basically impossible to build a virtual
memory system that scales as the system is used.
Specifically: Under MacOS, every application had to tell the system
the maximum amount of memory it would *ever* use. This was such that
the OS could set aside that much memory from physical+virtual for that
application (though it would start at a lower number, but above the
configured minimum, if necessary). It had to have this amount
effectively wired down because every app's memory is addressable from
every other application.
Under OS X (or any other system that uses protected memory combined with
a real virtual memory implementation), each process on the system lives
in its own address space. That is, any two (or more) processes may very
likely have a memory address like 0x123456 in their space and that
address will contain different data and be inaccessible to the other
processes.
Sounds slightly odd and maybe ineffecient. It is neither; the CPU
actually takes care of all of the address translation in a transparent
fashion that doesn't actually eat clock cycles [I believe-- on shaky
ground on that one, admittedly-- in any case, it is super effecient].
It is a huge benefit in that it means the operating system can add
virtual memory to any process as it requests more memory. I.e. a
process can grow over time as needed without the system wiring down the
maximum amount of memory as the app starts up.
By preventing apps from stomping all over each other, it yields a
massive increase in stability. There were certain apps or combinations
of apps on OS9 that I simply could not execute together without ending
with a reboot. Not so on OSX; Internet Explorer is free to crash all
day long without affecting other applications on my system. It simply
can't thrash the memory owned by Mail.app. Similarly, I no longer care
whether or not I quit applications. Because of the way the virtual
memory works, applications that are not in use will have their memory
pushed out to the disk as more physical memory is needed. Combine this
with a superior cooperative event model [event model, not tasking model]
and applications in the background really don't use system resources of
any noticeable amount. If I have a boatload of memory-- likely given
how cheap it is-- it is likely that the backgrounded applications will
stay in memory and be ready to go, if needed again.
--
It does make certain development tasks more difficult; passing data
between applications is an obvious feature that becomes more difficult
to implement because applications are protected from each other.
While more difficult to implement, the power available through the
various OS X APIs is such that a lot more options are open to the
developer.
In particular, the use of mach port messages allows one application to
pass a bunch of memory to another application such that:
- the memory is not copied, it is shared
- as soon as either application changes that memory, it'll be
copied such that they have individual copies
- if the receiving mach port is on a different machine, the memory
will be copied across the network in a transparent fashion
Obviously, this doesn't solve the problem of truly shared memory. For
that, true shared memory APIs are provided. These APIs allow one or
more process to map a hunk of memory such that it can be shared between
them. As well, the applications can control various permissions and
other information regarding the shared information. Read/Write
permissions are controlled in a fashion similar to chmod-- that is,
read/write access can be controlled per owner, per group, or per
everyone.
Unlike Mac OS, this allows an application to create a hunk of shared
memory that other apps could have read only access to until the
application decides that it should allow other applications to have
read/write access.
b.bum
On Monday, June 25, 2001, at 03:55 AM, email@hidden
wrote:
Date: Sun, 24 Jun 2001 20:13:40 -0700
To: Cocoa Developer <email@hidden>
From: Rosyna <email@hidden>
Subject: Re: Confusion
This is the sort of thing that was possible with the classic Mac OS,
a program could pass a pointer to another program via appleevents or
the like.