# RAM usage limits

Matthew Sanderson (m.sanderson@student.anu.edu.au)
Sun, 21 Apr 1996 14:06:36 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

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