Re: Determining reasonable memory use

• Subject: Re: Determining reasonable memory use
• From: Mike Kluev <email@hidden>
• Date: Mon, 31 Jan 2005 15:28:37 -0900
• Delivered-to: email@hidden
• Delivered-to: email@hidden
• User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

On 31/01/2005 02:56 Am, John Stiles wrote:

> On Jan 31, 2005, at 3:16 PM, Mike Kluev wrote:
> 
>> On 30/01/2005 11:30 Pm, Eric Schlegel wrote:
>> 
>>> On Jan 30, 2005, at 9:57 AM, Mike Kluev wrote:
>>> 
>>>> With the current "optimistic" implementation he will get back non
>>>> null
>>>> but may crash on attempt to write to that memory.
>>> 
>>> I don't believe that will actually ever happen (if it does, it's a
>>> bug;
>>> it _should_ never happen). If you overcommit your memory usage such
>>> that there's not enough disk space to fulfull it, the kernel will
>>> start
>>> blocking the threads of non-essential applications, allowing
>>> loginwindow to put up the "you've filled up your disk; please quit
>>> some
>>> apps" dialog box, which will free up enough memory to allow apps to
>>> continue running.
>> 
>> That's ok as long as:
>> - it works (I hope so)
>> - there is user nearby (server app? 4 AM?)
>> - there are apps to quit (or files to delete)
> 
> #1 - if it doesn't work, file a bug,

Sure. I'll test it when'll have more time.

> but it's worked when I've run across it.

> #2 - without user interaction, on a system with no available disk or
> memory resources, you really are stuck. There is no choice but to wait
> for someone to fix up the problem. The only real alternative would be
> to have automated resource-freeing (i.e. like Windows Cleanup--get rid
> of old log/temporary files, etc), and even then that will only briefly
> delay the inevitable, not solve the problem. The computer isn't
> generally allowed to make judgment calls like "this process or file is
> worth deleting so I can have more swapfile space"--and most people like
> it this way :)
> #3 - if there's nothing to quit or delete, once again, you really are
> stuck until an admin can delete or quit something non-essential.
> 
> There really isn't a magic bullet once you're out of resources... I
> don't know what you'd expect to happen in these situations.

The idea I proposed is for the system to carefully track allocations
and return NULL if it can't be satisfied:

>> Or carefully track memory usage and compare it to remaining space.
>> In other words, malloc should "reserve" vm space and this reservation
>> should be honored by other mallocs or file operations (!) and that
>> should be system wide. If that is true, then in the above example
>> NewHandle(.9GB) will fail and NewHandle(.4GB) will succeed.

So, if the app does something like this:

p = malloc(500 MB); // do it fast
if (!p) p = malloc(1 MB); // do it slower
if (!p) {
    // wow, really low on memory
    free(emergency 10 MB Block);
    // disable non essential operations
    // post notification about low memory
    p = malloc(1 MB); // this one should succeed
}
if (!p) something really bad happened, do what you usually do on NULL.

it might get back NULL for 500 MB allocation but still will be able
to continue (with no user intervention, thread blocking, app quitting,
and file deleting).

> Something 
> has to give, and in most situations only a human can decide what is
> really essential and what isn't. Yes, if there's dead air in the system
> somewhere, it would be nice to get it squeezed out, but if you're
> writing a VM system, you have to assume that at some point you will not
> have enough physical resources to satisfy incoming requests, and at
> that point you need a strategy for dealing with it. Blocking the thread
> about to overcommit, and asking the user to free up resources, is as
> good a policy as I could devise.

Let's disagree. Realistically I have to admit, that no matter how
much more I like my proposal than the current implementation, the
behavior of malloc is unlikely to change.

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

• Follow-Ups:
  • Re: Determining reasonable memory use
    • From: John Stiles <email@hidden>

• Prev by Date: Re: CG migration from QD
• Next by Date: Re: CG migration from QD
• Previous by thread: Re: Determining reasonable memory use
• Next by thread: Re: Determining reasonable memory use
• Index(es):
  • Date
  • Thread