[Prev][Next][Index][Thread]

# Re: Task RAM-usage limits...

- Date: Sat, 20 Apr 1996 00:07:08 PDT
- From:
- cc: moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <Pine.LNX.3.91.960419233930.697A-100000@darkowl.pr.mcs.net>

    On Fri, 19 Apr 1996, Don Schwarz wrote:

    > If any task going over a
    > certain amount of memory were simply killed, this could not happen.  So
    > while it is possible for important tasks to get killed, I think having a
    > memory quota for tasks would save a lot more trouble than it would cause.
    >
    > Not that I'm saying it would be trivial to do, I haven't looked at the code
    > but I'm sure there's no easy way to trace which verb called the malloc().
    > Another idea (or maybe someone already suggested this) is just to put a
    > limit on the total amount of memory that each task can use.

    Implementing this is much worse than not trivial, and even once it was
    done it would have its problems.  It's difficult to express just how deep
    the changes needed to make this happen would be.

    Figuring out how much memory a task is using is a very complicated matter.
    An executing task uses memory in a lot of places and ways, among them:
    keeping track of the function call stack, the variables in the current
    task, the code of all the verbs that the task is in the middle of running,
    temporary values needed to evaluate expressions, etc.  Calculating how
    much memory a task is using would be a *very* time-consuming task; not
    something we want to do very often at all.

    The alternative is to keep track of how the amount of memory we're using
    changes.  This is almost worse.  The problem is that literally
    *everything* we do changes the amount of memory we use; at least 80-90
    percent of the statements in the run function, which is responsible for
    actually executing code, change the amount of memory a task uses.  Aside
    from the amount of work that it makes to change it, it means that the
    server does a lot of extra work to keep track of memory usage.  I'd
    guess that the speed penalty might be as bad as halving the speed in some
    instances (for example, if we have a string, and pass it off to some
    accessory function, we won't know what it's going to do to our string, so
    we'll have to just count its length before and after, which turns out to
    be pretty slow.)  The interpreter's already slow enough; it just doesn't
    need this added on to it.

    Finally, from a purely practical point of view, I'd say it's fairly safe
    to say that the only person who knows the server well enought to
    implement this is Pavel, and he's not going to do it.  It's going to be
    some time before anyone becomes familiar enough with the server to do
    something of this magnitude.

    Would this be a nice thing to have?  Heck yes.  Is it possible?  Well, yes.
    Is it going to happen?  Doubtful.

    > Maybe there's a
    > good way to exempt certain tasks from this?

    This is the least of the problem, in my opinion.  If your task doesn't
    fit in, say, 10 megs (not even close to crashing a server with a
    reasonable amount of swap) something is wrong, even if you're the archwiz.

    > What if, instead of imposing a limit on the total amount of memory a task
    > could allocate, we just set a limit on the total amount of information one
    > Var could hold?  that would stop people from doing stuff like:
    >   ;;a = "--"; while(1) a = strsub(a, "-", a); endwhile      *and*
    >   ;;this.p = "--"; while(1) this.p = strsub(this.p, "-", this.p); endwhile

    Because, like I say above, the values in variables change so often that
    the overhead is astonishing.  Even if we only take variables, and not
    other values floating around (only have to deal with a few of the
    instructions, plus environment initialization) we're doing a lot of slow
    things a lot.

    > Of course this sounds like a pretty big change, so I'm sure Pavel won't be
    > doing it, but it's something to think about...

    It's so large, and so fundamental, a change that it's not something that
    can be practically hacked into LambdaMOO.  You're entirely right that
    it's something to consider, because it would be so nice to have.  But
    it's more something to think about when thinking about what the next
    generation of servers should be able to do.  Doing it efficently is a
    matter of the global organization of the way the interpreter (and
    therefore the parser and nearly everything else) runs; and thinking about
    the way the MOO runs code at that level is on par with other very large
    considerations like multiple inheritance and multi-tasking.

    In short, what you have are some very good ideas that unfortunately turn
    out to be very difficult to implement... :/

      --Chris                           cunkel@engin.umich.edu
        ResComp Network Support Technician, Bursley Hall
        "Invisibility is in the eye of the beholder."
        Home Page: http://www-personal.engin.umich.edu/~cunkel/

Follow-Ups:

- Re: Task RAM-usage limits...

- From: tom@mvision.com (Tom Ritchford)

References:

- Task RAM-usage limits...

- From: Don Schwarz <darkowl@darkowl.pr.mcs.net>

- Prev: Task RAM-usage limits...
- Next: Re: Task RAM-usage limits...
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index