MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | CONCEPT |
| 2 | memory |
| 3 | swapping |
| 4 | |
| 5 | DESCRIPTION |
| 6 | |
| 7 | TODO: This is out of date. Also document the relation with reset |
| 8 | |
| 9 | (Collected from the Changelogs of the driver source) |
| 10 | |
| 11 | The swapping algorithm has been changed. A test is done for |
| 12 | every object, comparing to a time stamp. If the object hasn't |
| 13 | been touched for a while, it could be subject for swapping. |
| 14 | Here comes the new thing: the function 'clean_up()' will be |
| 15 | called in the object. If the object still remains, the old |
| 16 | swapping algorithm will continue. That means that objects that |
| 17 | would never be subject to swapping (cloned objects) now have a |
| 18 | chance to self-destruct. It also means that rooms that |
| 19 | contains no important data can self-destruct. Self-destruction |
| 20 | saves more memory than swapping, as swapping only frees the |
| 21 | program code, while self-destruction also frees the internal |
| 22 | object representation. |
| 23 | |
| 24 | The call of clean_up() has been modified. There is a constant |
| 25 | in config.h that defines how long time until clean_up is |
| 26 | called in an object. This call is independent of reset() and |
| 27 | swapping. It is recommended that the swapping time is |
| 28 | something short, like 10 minutes to 30 minutes, while the time |
| 29 | to clean_up is longer. |
| 30 | |
| 31 | Fixed several bugs in the swap/reset/clean_up logic. |
| 32 | Recommended values are that the swap time is short (less than |
| 33 | 30 minutes), and that reset time is medium (aprox 60 minutes), |
| 34 | and that time to clean_up is long (greater than 1.5h hours). |
| 35 | Any feedback of how to best tune these values are welcome. The |
| 36 | call of reset will be done once, and not yet again until the |
| 37 | object has been touched. This enables reset'ed objects to stay |
| 38 | swapped out. If you have a mudlib that has no ojbects that |
| 39 | defines 'clean_up', then you may better define this time as 0, |
| 40 | which means never call clean_up (and thus never swap the |
| 41 | object in needlessly). A well implemented usage of clean_up is |
| 42 | better than the swap algorithm, as even cloned objects can be |
| 43 | cleaned up and a self destruction is more efficient than |
| 44 | swapping (memory wise). |
| 45 | |
| 46 | Changed mechanism of calling clean_up() slightly. Only objects |
| 47 | that defines the function will be called. And, only clean_up() |
| 48 | that returns non-zero will be called again. This will minimize |
| 49 | calls of clean_up(), while still cost very litte to maintain. |
| 50 | |
| 51 | clean_up() now gets a flag as argument, which will be non-zero |
| 52 | if the the program of this object is used for inheritance by |
| 53 | other objects. |
| 54 | |
| 55 | SEE ALSO |
| 56 | clean_up(A), slow_shut_down(M), quota_demon(M), malloc(D) |