Results 1 -
7 of
7
Barriers: Friend or Foe?
, 2004
"... Modern garbage collectors rely on read and write barriers imposed on heap accesses by the mutator, to keep track of references between different regions of the garbage collected heap, and to synchronize actions of the mutator with those of the collector. It has been a long-standing untested assumpti ..."
Abstract
-
Cited by 32 (5 self)
- Add to MetaCart
Modern garbage collectors rely on read and write barriers imposed on heap accesses by the mutator, to keep track of references between different regions of the garbage collected heap, and to synchronize actions of the mutator with those of the collector. It has been a long-standing untested assumption that barriers impose significant overhead to garbage-collected applications. As a result, researchers have devoted effort to development of optimization approaches for elimination of unnecessary barriers, or proposed new algorithms for garbage collection that avoid the need for barriers while retaining the capability for independent collection of heap partitions. On the basis of the results presented here, we dispel the assumption that barrier overhead should be a primary motivator for such efforts. We present a
Partial Redundancy Elimination for Access Path Expressions
- In CC
, 2001
"... Pointer traversals pose significant overhead to the execution of object-oriented programs, since every access to an object?s state requires a pointer dereference. Eliminating redundant pointer traversals reduces both instructions executed as well as redundant memory accesses to relieve pressure on t ..."
Abstract
-
Cited by 15 (7 self)
- Add to MetaCart
Pointer traversals pose significant overhead to the execution of object-oriented programs, since every access to an object?s state requires a pointer dereference. Eliminating redundant pointer traversals reduces both instructions executed as well as redundant memory accesses to relieve pressure on the memory subsystem. We describe an approach to elimination of redundant access expressions that combines partial redundancy elimination (PRE) with type-based alias analysis (TBAA). To explore the potential of this approach we have implemented an optimization framework for Java class files incorporating TBAA-based PRE over pointer access expressions. The framework is implemented as a class-file-to-class-file transformer; optimized classes can then be run in any standard Java execution environment. Our experiments demonstrate improvements in the execution of optimized code for several Java benchmarks running in diverse execution environments: the standard interpreted JDK virtual machine, a virtual machine using ?just-in-time? compilation, and native binaries compiled off-line (?way-ahead-of-time?). Overall, however, our experience is of mixed success with the optimizations, mainly because of the isolation between our optimizer and the underlying execution environments which prevents more effective cooperation between them.We isolate the impact of access path PRE using TBAA, and demonstrate that Java?s requirement of precise exceptions can noticeably impact code-motion optimizations like PRE.
Mostly-Copying Reachability-Based Orthogonal Persistence
- In OOPSLA '97 Workshop on Memory Management and Garbage Collection
, 1999
"... We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and reside ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and resident persistent objects, and to compute the reachability closure necessary for stabilization of the persistent heap. It has been implemented in our prototype of reachability-based persistence for Modula-3, yielding performance competitive with that of comparable, but non-orthogonal, persistent variants of C++. Experimental results, using the OO7 object database benchmarks, reveal that the mostly-copying approach offers a straightforward path to efficient orthogonal persistence in these uncooperative environments. The results also characterize the performance of persistence implementations based on virtual memory protection primitives. 1 Introduction Incorporating orthogonal persistence [11] ...
PM3: An Orthogonally Persistent Systems Programming Language -- Design, Implementation, Performance
- IN PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES
, 1999
"... PM3 is an orthogonally persistent extension of the Modula-3 systems programming language, supporting persistence by reachability from named persistent roots. We describe the design and implementation of the PM3 prototype, and show that its performance is competitive with its nonorthogonal coun ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
PM3 is an orthogonally persistent extension of the Modula-3 systems programming language, supporting persistence by reachability from named persistent roots. We describe the design and implementation of the PM3 prototype, and show that its performance is competitive with its nonorthogonal counterparts by direct comparison with the SHORE/C++ language binding to the SHORE object store. Experimental results, using the traversal portions of the OO7 benchmark, reveal that the overheads of orthogonal persistence are not inherently more expensive than for nonorthogonal persistence, and justify our claim that orthogonal persistence deserves a level of acceptance similar to that now emerging for automatic memory management (i.e., "garbage collection"), even in performance-conscious settings. The consequence will be safer and more flexible persistent systems that do not compromise performance.
Transparent program transformations in the presence of opaque code
- In GPCE
, 2006
"... User-level indirection is the automatic rewriting of an application to interpose code that gets executed upon program actions such as object field access, method call, object construction, etc. Several useful domain-specific and domain-independent (typically called aspect-oriented) mechanisms employ ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
User-level indirection is the automatic rewriting of an application to interpose code that gets executed upon program actions such as object field access, method call, object construction, etc. Several useful domain-specific and domain-independent (typically called aspect-oriented) mechanisms employ user-level indirection techniques for enhancing the capabilities of applications. Nevertheless, the applicability of all such techniques is constrained due to the presence of opaque (native) code that cannot be indirected and can invalidate the assumptions of any indirection transformation. These problems are real: the native behavior of Java system classes, for instance, invalidates the transparency of several user-level indirection techniques in the recent research literature. In this paper, we demonstrate the problem of employing user-level indirection in the presence of native code. We then suggest reasonable assumptions on the behavior of native code and a simple analysis to compute the constraints they entail for the applicability of user-level indirection. We show that the type information at the native code interface is often a surprisingly sufficient approximation of native behavior for heuristically estimating when user-level indirection can be applied safely. Furthermore, we introduce a new user-level indirection approach that minimizes the constraints imposed by interactions with native code.
Design of the persistence mechanisms
, 2001
"... Abstract. Barbados is a complete C++ persistent programming environment which runs on the top of Win32. It mainly consists of a C++ native-Pentium-code compiler, an integrated editor, a debugger, and a persistent store; the file system of traditional systems is substituted in Barbados by an object s ..."
Abstract
- Add to MetaCart
Abstract. Barbados is a complete C++ persistent programming environment which runs on the top of Win32. It mainly consists of a C++ native-Pentium-code compiler, an integrated editor, a debugger, and a persistent store; the file system of traditional systems is substituted in Barbados by an object store. Persistence consists of hiding the processes in which the data structures that a program uses are saved before finishing it and restored later when the program is again executed. In this technical report, the persistence basics of Barbados are explained, such as how persistent store, swizzling, clustering and language support are featured. This work pays special attention to the architectural approach to the above themes, principally in how they are solved in Barbados, other discarded possibilities and approaches …etc. Moreover, every layer in the Barbados ’ architecture is thoroughly explained.

