On 31/01/2005 03:55 Am, John Stiles wrote:
> In a perfect world I might agree, but the system just isn't as simple
> as you make it out to be. Here's an example.
>
> Each GUI process on your system right now is consuming a minimum of
> 200MB of virtual memory space. Some are significantly higher. You can
> verify this in Activity Viewer.
>
> Their real memory space is much smaller; it looks like a regular Carbon
> or Cocoa app that's not doing much takes about 4-8MB of real space.
> Some take less, some take more, of course, but the point is that
> they're almost always much smaller than 200MB :)
>
> Why is the VM size so much bigger than the actual size? That 200MB per
> process is because the system is sharing one copy of the common
> code/data with each app. Each app thinks it has its own copy of the
> code and data used by Carbon, Cocoa, HIViews, etc., but in reality the
> VM system is mirroring these pages to each process.
>
> However, at any instant, any of these apps could ask the VM system to
> turn off the memory protection on this 200MB block of memory and start
> scribbling on top of it.
I believe this is rather untypical situation, but see below.
> Do you let one rogue app write over the shared
> copy of Carbon.framework that every other app is using? Of course not;
> the VM system at this point uses copy-on-write to spawn in a local copy
> of the data so that the process has its own copy of the data to trash.
> Making this local copy, of course, takes resources.
>
> What do you do if the system is out of resources at that point? You're
> still in an "overcommitted" situation, even though there was no malloc
> called.
No malloc, but some other call was called to turn off the memory
protection. This is not my area of expertise, but let's assume
that this call could be designed to be able to fail and return
an error on lack of space (similar to the "pessimistic" malloc).
Same situation.
>>> Something has to give, and in most situations only a human can decide
>>> what is really essential and what isn't.
Looks like the major difference is here: whether to place
responsibility on a user, or on a app.
> That's why I think the current approach has merit.
Sure. Both do.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
