Results 1 -
7 of
7
An Efficient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes
, 1991
"... . We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF's lack of classes and explicit variables. To compensate for the absence of class ..."
Abstract
-
Cited by 150 (24 self)
- Add to MetaCart
. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF's lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver's map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline ma...
Optimizing dynamically-typed object-oriented languages with polymorphic inline caches
, 1991
"... Abstract. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF’s lack of classes and explicit variables. To compensate for the absence ..."
Abstract
-
Cited by 105 (9 self)
- Add to MetaCart
Abstract. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF’s lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver’s map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline many other messages. Inlining dramatically improves performance and eliminates the need to hard-wire low-level methods such as +, ==, and ifTrue:. Despite inlining and other optimizations, our system still supports interactive programming environments. The system traverses internal dependency lists to invalidate all compiled methods
Protection Traps and Alternatives for Memory Management of an Object-Oriented Language
, 1993
"... Many operating systems allow user programs to specify the protection level (inaccessible, read-only, read-write) of pages in their virtual memory address space, and to handle any protection violations that may occur. Such page-protection techniques have been exploited by several user-level algorithm ..."
Abstract
-
Cited by 46 (8 self)
- Add to MetaCart
Many operating systems allow user programs to specify the protection level (inaccessible, read-only, read-write) of pages in their virtual memory address space, and to handle any protection violations that may occur. Such page-protection techniques have been exploited by several user-level algorithms for applications including generational garbage collection and persistent stores. Unfortunately, modern hardware has made efficient handling of page protection faults more difficult. Moreover, page-sized granularity may not match the natural granularity of a given application. In light of these problems, we reevaluate the usefulness of pageprotection primitives in such applications, by comparing the performance of implementations that make use of the primitives with others that do not. Our results show that for certain applications software solutions outperform solutions that rely on page-protection or other related virtual memory primitives.
A Comparative Performance Evaluation of Write Barrier Implementations
, 1992
"... Generational garbage collectors are able to achieve very small pause times by concentrating on the youngest (most recently allocated) objects when collecting, since objects have been observed to die young in many systems. Generational collectors must keep track of all pointers from older to younger ..."
Abstract
-
Cited by 41 (11 self)
- Add to MetaCart
Generational garbage collectors are able to achieve very small pause times by concentrating on the youngest (most recently allocated) objects when collecting, since objects have been observed to die young in many systems. Generational collectors must keep track of all pointers from older to younger generations, by "monitoring " all stores into the heap. This write barrier has been implemented in a number of ways, varying essentially in the granularity of the information observed and stored. Here we examine a range of write barrier implementations and evaluate their relative performance within a generation scavenging garbage collector for Smalltalk. 1 Introduction Generational collectors achieve short collection pause times partly because they separate heap-allocated objects into two or more generations and do not process all generations during each collection. Empirical studies have shown that in many programs most objects die young, so separating objects by age and focusing collecti...
Remembered Sets Can Also Play Cards
- In OOPSLA'93 Workshop on Garbage Collection and Memory Management
, 1993
"... Remembered sets and dirty bits have been proposed as alternative implementations of the write barrier for garbage collection. There are advantages to both approaches. Dirty bits can be efficiently maintained with minimal, bounded overhead per store operation, while remembered sets concisely, and acc ..."
Abstract
-
Cited by 21 (1 self)
- Add to MetaCart
Remembered sets and dirty bits have been proposed as alternative implementations of the write barrier for garbage collection. There are advantages to both approaches. Dirty bits can be efficiently maintained with minimal, bounded overhead per store operation, while remembered sets concisely, and accurately record the necessary information. Here we present evidence to show that hybrids can combine the virtues of both schemes and offer competitive performance. Moreover, we argue that a hybrid can better avoid the devils that are the downfall of the separate alternatives. 1 Introduction Generational garbage collectors [6, 10, 11] achieve short pause times partly because they separate heap-allocated objects into two or more generations and do not process all generations during each collection. Empirical studies have shown that in many programs most objects die young, so separating objects by age and focusing collection effort on the younger generations is a popular strategy. However, any ...
Incremental Mature Garbage Collection
, 1993
"... Many programming languages provide automatic garbage collection to reduce the need for memory management related programming. However, traditional garbage collection techniques lead to long and unpredictable delays and are therefore not satisfactory in a number of settings, such as interactive syste ..."
Abstract
-
Cited by 9 (0 self)
- Add to MetaCart
Many programming languages provide automatic garbage collection to reduce the need for memory management related programming. However, traditional garbage collection techniques lead to long and unpredictable delays and are therefore not satisfactory in a number of settings, such as interactive systems, where non-disruptive behavior is of paramount importance. Advanced techniques, such as generation-based collection, alleviate the problem somewhat by concentrating collection efforts on small but hopefully gainful areas of memory, the so-called young generations. This approach reduces the need for collecting the remaining large memory area, the old generation, but in no way obviates it. Traditionally, conventional techniques have been employed for old generation collection, leading to pauses which, although less frequent, are still highly disruptive. Recently, however, Hudson & Moss have introduced a new algorithm, the Train Algorithm, for performing efficient incremental collection of o...
Lightweight Write Detection and Checkpointing for Fine-Grained Persistence
, 1995
"... INTRODUCTION A persistent system #Atkinson et al. 1982; Atkinson et al. 1983; Atkinson et al. 1983; Atkinson and Buneman 1987# maintains data independently of the transitory programs that create and manipulate that data---data may outlive their creators, and be manipulated by yet other programs. To ..."
Abstract
-
Cited by 6 (4 self)
- Add to MetaCart
INTRODUCTION A persistent system #Atkinson et al. 1982; Atkinson et al. 1983; Atkinson et al. 1983; Atkinson and Buneman 1987# maintains data independently of the transitory programs that create and manipulate that data---data may outlive their creators, and be manipulated by yet other programs. To achieve this, persistent systems provide an abstraction of persistent storage, which programmers view as a stable This work has been supported by the National Science Foundation under grants CCR-9211272, CCR-8658074 and DCR-8500332, and by the following companies and corporations: Sun Microsystems, Digital Equipment, Apple Computer, GTE Laboratories, Eastman Kodak, General Electric, ParcPlace Systems, Xerox, and Tektronix. Name: Antony L. Hosking A#liation: Purdue University Address: Department of Computer Sciences, Purdue University,West Lafayette, IN 47907-1398, hosking@cs.purdue.edu Name: J. Eliot B. Moss A#liation: University of Massachuset

