Re: RAM usage limits

• Date: Sun, 21 Apr 1996 14:06:36 PDT
• From:
  m.sanderson@student.anu.edu.au (Matthew Sanderson)
• Content-Type: text/plain; charset="us-ascii"

At 1:02 AM 4/21/96, Christopher Unkel wrote:
>I don't see what this accomplishes, or how.  How do we find the guilty
>task?  How do we know that it's a runaway task at fault, and not natural
>database growth or gradual memory usage increase as a result of memory
>fragmentation?  What if it's more than one task?

A dynamically-computed, rather than static, RAM usage limit for a task
might solve this partially... but yuk. Something along the lines of 'task
is using more memory than size of database', or 'task's usage is already
big, and growing quickly'. Or something like that.
In certain cases it'd be very obvious that there's one task that is
definitely _not_ doing anything useful because of sheer memory- and
time-usage, and would therefore safe to kill.
Even the modest aim of catching these very obvious cases would be a nice
added line of defence...

>Furthermore, since this is a MOO task, it can only happen when other
>tasks aren't running.  We accomplish a heck of a lot more by checking the
>process size at regular intervals in the MOO-code executor.  (For
>example, we can decide to stop executing a task if the process size
>increase by 20 megs inside while inside that task, which is probably a sign
>that Bad Things (TM) are happening.  This is where I thought things were
>headed before...)

Sounds good.

>1) Place a maximum size on the environment (variables in all frames) that
>a task can have when it suspends.
  :
  :
>2) Place a maximum size on the amount of data a single property can hold.
>Goal:
>  To protect against the analagous and arguably more dangerous case:
>    foo.bar="ouch!";
>    while (1)
>      foo.bar=foo.bar+foo.bar;
>      $command_utils:suspend_if_needed(0);
>    endwhile
>   which is as effective as the above, but the damage is saved in the
>   panic file.

A limit placed on the size of the values a MOO task uses (as you propose
for variables in '1)') would solve this case, too, if the checking were
done during evaluation of 'foo.bar + foo.bar', and not at the suspend.
What I'm really describing is a size-limit not only on the task's
variables, but on values it manipulates, references, stores, etc. Values
stored in variables, values being evaluated before being assigned to
properties, ...
I can see this would involve one helluva lot more overhead...

Matthew Sanderson
m.sanderson@student.anu.edu.au
The Australian National University, Canberra.

===========================================================================
"Computers in the future may weigh no more than 1.5 tons."
     --Popular Mechanics, forecasting the relentless march of science, 1949
===========================================================================

• Prev: Re: RAM usage limits
• Next: Re: Re[2]: Verbing Properties (forwarded from "Seth I. Rich"<sir@po.cwru.edu
• Index: MOO-cows
• Thread: MOO-cows