Efficient Proxies in Smalltalk

International audienceA proxy object is a surrogate or placeholder that controls access to another target object. Proxy objects are a widely used solution for different scenarios such as remote method invocation, future objects, behavioral reflection, object databases, inter-languages communications and bindings, access control, lazy or parallel evaluation, security, among others. Most proxy implementations support proxies for regular objects but they are unable to create proxies for classes or methods. Proxies can be complex to install, have a significant overhead, be limited to certain type of classes, etc. Moreover, most proxy implementations are not stratified at all and there is no separation between proxies and handlers. In this paper, we present Ghost, a uniform, light-weight and stratified general purpose proxy model and its Smalltalk implementation.Ghost supports proxies for classes or methods. When a proxy takes the place of a class it intercepts both, messages received by the class and lookup of methods for messages received by instances. Similarly, if a proxy takes the place of a method, then the method execution is intercepted too

Marea: An Efficient Application-Level Object Graph Swapper

International audienceAbstract During the execution of object-oriented applications, several millions of objects are created, used and then collected if they are not referenced. Prob- lems appear when objects are unused but cannot be garbage-collected because they are still referenced from other objects. This is an issue because those ob- jects waste primary memory and applications use more primary memory than they actually need. We claim that relying on the operating system's (OS) virtual memory is not always enough since it cannot take into account the domain and structure of applications. At the same time, applications have no easy way to parametrize nor cooperate with memory management. In this paper, we present Marea, an efficient application-level object graph swapper for object-oriented programming languages. Its main goal is to offer the programmer a novel so- lution to handle application-level memory. Developers can instruct our system to release primary memory by swapping out unused yet referenced objects to secondary memory. Our approach has been qualitatively and quantitatively val- idated. Our experiments and benchmarks on real-world applications show that Marea can reduce the memory footprint between 23% and 36%

Ghost: A uniform and general-purpose proxy implementation

International audienceA proxy object is a surrogate or placeholder that controls access to another target object. Proxy objects are a widely used solution for different scenarios such as remote method invocation, future objects, behavioral reflection, object databases, inter-languages communications and bindings, access control, lazy or parallel evaluation, security, among others. Most proxy implementations support proxies for regular objects but are unable to create proxies for objects with an important role in the runtime infrastructure such as classes or methods. Proxies can be complex to install, they can have a significant overhead, they can be limited to certain kind of classes, etc. Moreover, proxy implementations are often not stratified and they do not have a clear separation between proxies (the objects intercepting messages) and handlers (the objects handling interceptions). In this paper, we present Ghost: a uniform and general-purpose proxy implementation for the Pharo programming language. Ghost provides low memory consuming proxies for regular objects as well as for classes and methods. When a proxy takes the place of a class, it intercepts both the messages received by the class and the lookup of methods for messages received by its instances. Similarly, if a proxy takes the place of a method, then the method execution is intercepted too

Problems and Challenges when Building a Manager for Unused Objects

International audienceLarge object-oriented applications may occupy hundreds of megabytes or even gigabytes of memory. During program execution, a large graph of objects is created and constantly changed. Most object runtimes support some kind of automatic memory management based on garbage collectors (GC) whose idea is the automatic destruction of unreferenced objects. However, there are referenced objects which are not used for a long period of time or that are used just once. These are not garbage-collected because they are still reachable and might be used in the future. Due to these unused objects, applications use much more resources than they actually need. In this paper we present the challenges and possible approaches towards an unused object manager for Pharo. The goal is to use less memory by swapping out the unused objects to secondary memory and only leaving in primary memory only those objects which are needed and used. When one of the unused objects is needed, it is brought back into primary memory

Problems and Challenges when Building a Manager for Unused Objects

International audienceLarge object-oriented applications may occupy hundreds of megabytes or even gigabytes of memory. During program execution, a large graph of objects is created and constantly changed. Most object runtimes support some kind of automatic memory management based on garbage collectors (GC) whose idea is the automatic destruction of unreferenced objects. However, there are referenced objects which are not used for a long period of time or that are used just once. These are not garbage-collected because they are still reachable and might be used in the future. Due to these unused objects, applications use much more resources than they actually need. In this paper we present the challenges and possible approaches towards an unused object manager for Pharo. The goal is to use less memory by swapping out the unused objects to secondary memory and only leaving in primary memory only those objects which are needed and used. When one of the unused objects is needed, it is brought back into primary memory

Object Swapping Challenges: an Evaluation of ImageSegment

International audienceIn 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

Experiments with a Fast Object Swapper

International audienceIn 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 (e.g., a hard disk) to temporary release part of the primary memory. While exporting and swapping are achieved in different ways, each of them faces a common and central problem which is the speed of the approach in presence of large object graphs. Nevertheless, most of the existing solutions do not address well this issue. Another challenge is to deal with extremely 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 most of the general problems of 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

PLOMO Associate Team Final Report

The goal of Plomo is to develop new meta tools to improve and bring synergy in the existing infrastructure of Pharo1 (for software development) and the Moose software analysis platform2 (for maintenance). PLOMO will (i) enhance the Opal open compiler infrastructure to support plugin definition, (ii) offer an infrastructure for change and event tracking as well as models to compose and manipulate them, (iii) work on a layered library of algorithms for the Mondrian visualization engine of Moose, (iv) work on new ways of profiling applications. All the efforts will be performed on Pharo and Moose, two platforms heavily used by the RMoD and Pleiad teams

Fuel: A Fast General Purpose Object Graph Serializer

International audienceSince objects need to be stored and reloaded on different environments, serializing object graphs is a very important activity. There is a plethora of serialization frameworks with different requirements and design trade-offs. Most of them are based on recursive parsing of the object graphs, an approach which often is too slow. In addition, most of them prioritize a language-agnostic format instead of speed and language-specific object serialization. For the same reason, such serializers usually do not support features like class-shape changes, global references or executing pre and post load actions. Looking for speed, some frameworks are partially implemented at Virtual Machine (VM) level, hampering code portability and making them difficult to understand, maintain and extend. In this paper we present Fuel, a general-purpose object serializer based on these principles: (1) speed, through a compact binary format and a pickling algorithm which invests time in serialization for obtaining the best performance on materialization; (2) good object-oriented design, without special help at VM; (3) serialize any object, thus have a full-featured language-specific format. We implement and validate this approach in Pharo, where we demonstrate that Fuel is faster than other serializers, even those with special VM support. The extensibility of Fuel made possible to successfully serialize various objects: classes in Newspeak, debugger stacks, and full CMS object graphs

Run-time Variability with First-class Contexts

Software must be regularly updated to keep up with changing requirements. Unfortunately, to install an update, the system must usually be restarted, which is inconvenient and costly. In this dissertation, we aim at overcoming the need for restart by enabling run-time changes at the programming language level. We argue that the best way to achieve this goal is to improve the support for encapsulation, information hiding and late binding by contextualizing behavior. In our approach, behavioral variations are encapsulated into context objects that alter the behavior of other objects locally. We present three contextual language features that demonstrate our approach. First, we present a feature to evolve software by scoping variations to threads. This way, arbitrary objects can be substituted over time without compromising safety. Second, we present a variant of dynamic proxies that operate by delegation instead of forwarding. The proxies can be used as building blocks to implement contextualization mechanisms from within the language. Third, we contextualize the behavior of objects to intercept exchanges of references between objects. This approach scales information hiding from objects to aggregates. The three language features are supported by formalizations and case studies, showing their soundness and practicality. With these three complementary language features, developers can easily design applications that can accommodate run-time changes