Object Swapping Challenges - an Evaluation of ImageSegment
Last updated at 9:42 am UTC on 30 March 2017
https://hal.inria.fr/hal-00646897
Mariano Martinez Peck 1, Noury Bouraqadi, Stéphane Ducasse, Luc Fabresse
Mariano Martinez Peck, Noury Bouraqadi, Stephane Ducasse, Luc Fabresse. Object Swapping
Challenges: an Evaluation of ImageSegment. Computer Languages, Systems and Structures,
Elsevier, 2011, 38, pp.1-15.
<10.1016/j.cl.2011.10.001>
<hal-00646897>
Abstract
Abstract : In object-oriented systems, runtime memory is composed of an object graph in which objects refer to other objects. This graph of objects evolves while the system is running. Graph exporting and swapping are two important object graph operations. Exporting refers to copying the graph to some other memory so that it can be loaded by another system. Swapping refers to moving the graph to a secondary memory (for example, a hard disk) to temporary release part of the primary memory (for example, RAM). Exporting and swapping are achieved in different ways and the speed in presence of large object graphs is critical. Nevertheless, most of the existing solutions do not address well this issue. Another challenge is to deal with common situations where objects outside the exported/swapped graph point to objects inside the graph. To correctly load back an exported subgraph, it is necessary to compute and export extra information that is not explicit in the object subgraph. This extra information is needed because certain objects may require to be reinitialized or recreated, to run specific code before or after the loading, to be updated to a new class definition, etc. In this paper, we present all general problems to our knowledge about object exporting and swapping. As a case of study, we present an analysis of ImageSegment, a fast solution to export and swap object graphs, developed by Dan Ingalls. ImageSegment addresses the speed problems in an efficient way, as shown by the results of several benchmarks we have conducted using Pharo Smalltalk. However, ImageSegment is not a panacea since it still has other problems that hampers its general use.
Excerpt:
4.1 In the ImageSegment’s object swapping implementation, there is a list of user defined root objects that are
the base of the graph. The graph is then stored in an ImageSegment. Once this is done, the ImageSegment can be swapped to disk and the original objects are removed from the Smalltalk image.
In ImageSegment not all the objets from the graph are included in the swapped graph. Only the objects which are only accessible from objects inside the graph are included.
ImageSegment's export functionality uses SmartRefStream.
SmartRefStream stores enough information in the file about the names of the instance variables of all outgoing classes.
6.1. Benchmark and Analysis of Objects Export
Unsurprisingly, our experiments show that ImageSegment is much faster then SmartRefStream.
The benchmark shows that ImageSegment is ten times faster to export and thirty times faster to import.
Still, the ImageSegment export implementation uses SmartRefStream to serialize the ImageSegment object.
This leads us to an interesting question: Why serializing an ImageSegment (that contains an object graph) with SmartRefStream is much faster than just serializing the same object graph directly with SmartRefStream (without using ImageSegment)?
In SmartRefStream, the complete object graph has to be traversed in the image side (Smalltalk). But when an ImageSegment is created, the traversal of the object graph is done at the Virtual Machine level.
As a result of such procedure, the ImageSegment has an encoded WordArray representing the processed object
graph. This array is ready to be exported, there is no need to traverse it. Furthermore, ImageSegment uses the GarbageCollector marking algorithm which is optimized and also performed at the Virtual Machine side.
