UOX3.org

Currently we have a problem which is best seen by running a 'wipe command on a large world. The expected outcome is an enormous jump in memory usage (which is never freed entirely) and an eventual server crash.


The cause of the problem is this. Everytime we pass a new object (IE an item or character) to the JS engine, we must create a JSObject for it. This is done quite well in our events, as we allocate some memory once at script creation, and then re-use those entries in every event call. However when an object method or property, or JS function allocates an object, we have no good method of de-allocation. Thus when we call something like obj.owner, it allocates that memory, but never releases it after the script has fired.

The root of the problem is a lack of any good way to track our JSObjects. This is largely because the JSObjects are divided up among scripts, of which there are hundreds, and could be thousands of. This method of implementation, however, was not the intent of the Spidermonkey authors.



As you can see by this graph, the idea is that JSObjects are created by a general handler for that Runtime, and then each individual context and script can make use of them.

Thus I think we should create a new class that will house all of our JSObjects, ensuring that we have at a maximum only one per real object (so we don't have 1 item with 10 JS Objects attached to it). Moreover, this class must have an improved way to track these objects so we can call some type of general release function as soon as the object is no longer in use by any script.

Thoughts, suggestions, ideas, etc are welcome.[/img]

I'm not shure if any of this is possible but it would be some nice additions:

1. Assign a timer to the JSObjects, reset the timer everytime they are used and de-allocate them once the time is up. To not waste memory on objects that are only used once or twice.

2. Set a maximum ammount of memory to be used by the JSObjects, store the last access time of each object and if we reach the memory limit de-allocate the JSObject(s) whose access time is most in the past (I don't know how to correctly say that in english ).

Edit for number 2, if you can't get the ammount of memory currently used by the JSObjects a configurable maximum number of them would do also. This is mainly to prevent really big memory spikes.

3. Add a simple timer to run the JS garbage collection on user defined intervals. Because on bigger servers the world save might be set to only run every hour or hours, as it takes quite some time with big worlds.

A combination of those additions would make a nice system that keeps heavy used JSObjects in memory but also conserves memory where possible.

This would especially help with intense operations like IterateOver( ). Because even when de-allocating the JSObjects after it has run, the memory spike while it runs can become quite big, possibly to big if you have a server well filled with items/chars.