MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Task RAM-usage limits...

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: References:
Home | Subject Index | Thread Index