| Path: | lib/mues/os-extensions/trainmemorymanager.rb (CVS) |
| Last Update: | Sat Aug 18 22:54:10 -0700 2007 |
This file contains the TrainMemoryManager class: an incremental memory manager scheme, to allow for non-disruptive management of the ObjectStore system.
This is proof of concept only. The actual implementation of an incremental mature garbage collector using the train algorithm in ruby does not involve reference counting of any kind. See ImprovedTrainMemoryManager.rb for details.
Data structure:
The collection algorithm on the aforementioned data structure is as follows: Two threads exist - one for the determination of an object‘s maturity, the other for the incremental "deletion" of those objects. Maturity is determined by the ObjectSpaceVisitor#visit method, which is set by the environment defining the object space, and is a simple boolean value as to whether or not the environment has immediate need of said object. This should have nothing to do with reference counts. Once "matured", an object is passed onto the train-yard of the second thread.
The train thread is mostly just a continuous loop that calls one method and pauses. This pause is determined actively by looking at the ratio of mature objects to total objects, and trying to maintain that at a certain level. When the ratio has too much garbage, the pause length is shortened; when too low, it is lengthened. It can also be reset manually for a short-term change in behavior by the train thread.
The method called from within the train thread does the following with the train-yard: only one car is ever considered: the oldest (first) car of the oldest (first) train. (Without considering references, it would just be collected at this point, but that‘s makes useless the train part of this algorithm.) Now, the references TO the objects in this car are considered. If the only references that point to any objects in this car come from objects on this train, the car is collected (or the whole train, as we‘ll see later, but this could cause unacceptable lags for enormous structures). Each object that IS referenced from outside this train is moved onto the last (newest) train that references the object, or if the reference comes from outside mature object space, the object is treated as a newly matured object, and moved onto the last train in the yard. The remaining objects must have references within this train, and are therefor put onto the end of this (the oldest) train. In this way, it can be seen that datastructures will all be kept together in a train, and that once the front car is reference solely by objects within its train, the entire train must be a single datastructure, and can therefore be removed entirely.
For information on what is modeled here, see: www.daimi.aau.dk/~beta/Papers/Train/train.html
This is just proof of concept, and so isn't clean and professional, and is not being maintained. For actual use, please see ImprovedTrainMemoryManager.rb.
$Id: trainmemorymanager.rb 1206 2004-05-09 21:25:11Z deveiant $
Copyright (c) 2000-2003 The FaerieMUD Consortium. All rights reserved.
This module is free software. You may use, modify, and/or redistribute this software under the terms of the Perl Artistic License. (See language.perl.com/misc/Artistic.html)
THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.