| Export/Import of Plurix Heap Objects | |
|
The persistent virtual memory of Plurix makes a traditional file-system superfluous. Hence complex
serialization and deserialization functions required for file loading and saving are avoided. The first
Plurix prototype provides persistence by a central cluster server. During the shutdown of a node it
transmits all its pages to the central page server. If the node joins the cluster again it might request
its pages again from the page server. The uniform Plurix name service makes all named objects accessible.
A global root pointer is foreseen for all global public objects. In this semester project two different import/export functions should be developed. First of all simple string objects should be exportable as ASCII texts to the non-Plurix world. The opposite operation, importing ASCII files from non-Plurix systems should be possible too. Furthermore any heap object should be exportable and importable, e.g. for backup reasons. The latter operations require serialization and deserialization of heap objects. There are different heap object categories: class-, interface descriptors, code segments, instances and arrays. Any heap object can be exported, except code segments which are always associated with a class descriptor. If an object O need to be exported, all objects reachable from O need to be exported too. Reachability of an object implies that there are references to an object. E.g. exporting an instance requires the export of the associated class descriptor which is referenced by the type pointer of the instance. Hence the export algorithm needs to export the transitive closure of all objects reachable from the object O. For this purpose all references need to be identified. Fortunately all Plurix runtime structures have a bidirectional memory layout separating references and scalars. Hence all references of any heap object are easily locatable. Importing a class descriptors CD needs special attention. First of all it has to be checked if CD is still present in the Plurix heap. This search works on the public global scope and the users private scope. If CD has been found it must not be duplicated. All following instances are attached to the existing CD. The identification of class descriptors cannot rely on name comparison because name collisions would cause serious conflicts. Therefore Plurix uses a Global Unique Identification Number (GUIN) similar to the UUID of MS-Windows. Milestones:
Ulrich Schmid - Semester Project
1999 |
|