Potential method for stopping 'grey goo'

I've been giving this matter a bit of serious thought, been looking at the forums, been looking at the blog, and then looking at things from a couple of different perspectives... and think there may well be a way to slow or stop the problem completely, looking at it from a biological perspective.

The term 'grey goo' refers to a unregulated von neumann machine. Perhaps it would be best at that point to look at it as a viral (or perhaps fungal) infection, as a living thing that requires resources and grows.

So... the best way perhaps to deal with 'grey goo' is to starve it. Within the database system itself, perhaps an additional field could be added, (on a per-avatar, or per-simulator basis) regarding the number of calls by an object, multiplied or added to child object calls, to the rezzing functions (or IM functions, or other easily abused functions) that assigns a cost, and something within each child object that calls back to the parent on a rezzing call

i.e. llRezAtRoot, llRezObject, etc. Part of this perhaps could be accomplished with a hidden on_rez call back to the parent object, or to the simulator object storage, creating a heirarchical tree of objects created (can be a simple AVL/filetree system, or as simple as a binary hash) In general, practical use these would generally be small, but each object within that tree that also calls the llRez(whatever) function would assign a cost to the root object. (the cost could decrement a number, or increment, doesn't matter, net effect is the same) For each level of child object, a multiplier to the cost is incurred.

(edit) In addition, perhaps if the original root object is deleted, perhaps garbage collection should automatically start for child objects? (/edit)

Say that the root object starts with 500 points. For the first level of rezzing, it's x points. The moment child objects start rezzing, wherever they are within the tree, the root of the tree is assigned the debits of the child object rezzing. If the simulator (or database backend) finds that there is a low enough cost, all further calls are delayed. If the simulator later finds there is no room left in the pool of points (out of food) it causes extinction on the chain. (does either an explicit kill and deletion of the prims, or a return).

Add to this a system that monitors how many objects are rezzing in a sim, oh, say every few minutes, and should they grow too rapidly, also does a slowdown sim-wide on object rezzing, as well as a sim-wide slowdown on object returns in order to protect the asset server. (as per the Linden post on the blog)

This would allow the one minute autoreturn to remain, while still protecting the system, and the users... perhaps it would be the best of both worlds, but can people suggest a caveat involved?

Another thing I'm potentially seeing as a problem is the size of the object array for tracking self-rezzing objects.

Daelyn: Who has not had coffee and apologizes for rambling.

This would break artificial life.

Perhaps so, and likely so in fact, I need to check out 'artificial life' at some point, but you could also adjust the count as objects rezzed 'die'. This is precisely why I put up this suggestion, because I need to see where it might cause problems, and discussion may lead to solution.