Computer Languages, Systems & Structures

Computer Languages, Systems & Structures
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 anothersystem. Swapping refers to moving the graph to a secondary memory (e.g., a hard disk) to temporary release part of the primary memory (e.g., RAM).
Exporting and swapping are achieved in different ways and the speed in the 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 whereobjects 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 newclass 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 Ingalls. ImageSegment addresses the speed problems in an efficient way, as shown by the results of several benchmarks we have conducted using PharoSmalltalk. However, ImageSegment is not a panacea since it still has other problem that hampers its general use.
Keywords
* Object swapping;
* Serialization;
* ImageSegment;
* Smalltalk;
* Object-oriented programming

1. Introduction
The object-oriented programming paradigm has been widely accepted in the last decades. Nowadays, it is the most common programming paradigm andis applied from very small systems to large ones as well as from small devices to huge servers. Since generally in this paradigm objects point to other objects, the runtime memory is represented by an object graph.
This graph of object lives while the system is running and dies when the system is shutdown. However, sometimes it is necessary, for example, to backup a graph of objects into anon-volatile memory to load it back when necessary, or to export them so that they can be loaded in a different system. The same happens when doing migrations or when communicating with different systems.
Most applications need to persist graphs of objects so that they are not lost when shutting down the system. This is known as “persistency” and a general solution is to have a database that takes careof this problem.
In addition to this, large applications may occupy a lot of memory (hundreds of megabytes or even gigabytes). Therefore, application spatial scalability requires to temporarily swap out unused object graphs from primary memory (e.g., RAM) to secondary memory (e.g., hard disk) [8]. The intention behind this is to save primary memory or, even more, to be able to run moreapplications in the same amount of memory. The same happens with systems that run in embedded devices or in any kind of hardware with a limited amount of memory like robots, cellphones, PDAs, etc. In these cases, swapping out unused object saves memory, but it should not lead into thrashing as this will degrade the system's performance. By trashing we refer to the situation where data is rapidly written toand read from different types of memory, i.e., constant data swapping.
Approaches and tools to export and swap object graphs are needed. One of the biggest problems (and difficult to solve) with export or swap solutions is their performance. The approach must scale to large object graphs. However, most of the existing solutions do not solve this issue properly. This is usually because there is...