Portable run-time type description for conventional compilers

Kakkad, Sheetal V.; Johnstone, Mark S.; Wilson, Paul R.

doi:10.1145/301589.286876

“…We have designed Persistent Modula-3 for a move to compiler-inserted barriers in later versions, without needing to change the mostly-copying heap management mechanism. Just 'as easily, one might re-engineer the Texas persistent store to provide mostly-copying persistence by reachability for C++, based on the heap layout information for swizzling that Texas extracts from debugging information provided by the GNU C++ compiler [56].…”

Section: Storage Architecture Flexibilitymentioning

confidence: 99%

Mostly-copying reachability-based orthogonal persistence

Hosking

¹

,

Chen

²

1999

View full text Add to dashboard Cite

We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula3, 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 007 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.

show abstract

“…This is not to say that C++ itself will not succumb to orthogonal persistence. In fact, we are also exploring this possibility through extension of Texas with persistence by reachability, by marrying a garbage collector to Texas's portable run-time type descriptors [56] to obtain accurate information on the location of references stored in the heap.…”

Section: Performancementioning

confidence: 99%

“…We have designed Persistent Modula-3 for a move to compiler-inserted barriers in later versions, without needing to change the mostly-copying heap management mechanism. Just 'as easily, one might re-engineer the Texas persistent store to provide mostly-copying persistence by reachability for C++, based on the heap layout information for swizzling that Texas extracts from debugging information provided by the GNU C++ compiler [56]. A traced reference type REF T refers to heap-allocated storage (of type T) that is automatically reclaimed by the garbage collector whenever there are no longer any references to it.3 The type REFANY contains all references.…”

Section: Storage Architecture Flexibilitymentioning

confidence: 99%

Mostly-copying reachability-based orthogonal persistence

Hosking

¹

,

Chen

²

1999

Proceedings of the 14th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications

View full text Add to dashboard Cite

We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula3, 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 007 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.

show abstract

“…Another possibility would be to obtain layout information for objects from compiler debug output, as in Wilson's type descriptor generator system, even though this technique is less portable. 26 Beard 27 suggested the use of Cϩϩ pointers to member for implementing traverse(). Each class would contain a static table with pointers to members of the class that are pointers to collected objects.…”

Section: Using the Defaultheapmentioning

confidence: 99%

“…Another possibility would be to use the technique of Run Time Type Description 26 in order to obtain the layout information for objects needed by the collector to perform tracing.…”

Section: Applicabilitymentioning

confidence: 99%

A customisable memory management framework for C++

Attardi

¹

,

Flagella

²

,

Iglio

³

1998

Softw: Pract. Exper.

View full text Add to dashboard Cite

SUMMARYAutomatic garbage collection relieves programmers from the burden of managing memory themselves and several techniques have been developed that make garbage collection feasible in many situations, including real time applications or within traditional programming languages. However, optimal performance cannot always be achieved by a uniform general purpose solution. Sometimes an algorithm exhibits a predictable pattern of memory usage that could be better handled specifically, delaying as much as possible the intervention of the general purpose collector. This leads to the requirement for algorithm specific customisation of the collector strategies. We present a dynamic memory management framework which can be customised to the needs of an algorithm, while preserving the convenience of automatic collection in the normal case. The Customisable Memory Manager (CMM) organises memory in multiple heaps. Each heap is an instance of C؉؉ class which abstracts and encapsulates a particular storage discipline. The default heap for collectable objects uses the technique of mostly copying garbage collection, providing good performance and memory compaction. Customisation of the collector is achieved exploiting object orientation by defining specialised versions of the collector methods for each heap class. The object-oriented interface to the collector enables coexistence and coordination among the various collectors as well as integration with traditional code unaware of garbage collection. The CMM is implemented in C؉؉ without any special support in the language or the compiler. The techniques used in the CMM are general enough to be applicable also to other languages. The performance of the CMM is analysed and compared to other conservative collectors for C/C؉؉ in various configurations.

show abstract

Portable run-time type description for conventional compilers

Cited by 3 publications

References 3 publications

Mostly-copying reachability-based orthogonal persistence

Mostly-copying reachability-based orthogonal persistence

Mostly-copying reachability-based orthogonal persistence

A customisable memory management framework for C++

Contact Info

Product

Resources

About