Concurrent object-oriented programming (COOP) languages focus the abstraction and encapsulation power of abstract data types on the problem of concurrency control. In particular, pure fine-grained concurrent object-oriented languages (as opposed to hybrid or data parallel) provides the programmer with a simple, uniform, and flexible model while exposing maximum concurrency. While such languages promise to greatly reduce the complexity of large-scale concurrent programming, the popularity of these languages has been hampered by efficiency which is often many orders of magnitude less than that of comparable sequential code. We present a sufficient set of techniques which enables the efficiency of fine-grained concurrent object-oriented languages to equal that of traditional sequential languages (like C) when the required data is available. These techniques are empirically validated by the application to a COOP implementation of the Livermore Loops. 1 Introduction The increasing use of ...

Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.

While ne-grained concurrent languages can naturally capture concurrency in many irregular and dynamic problems, their exibility has generally resulted in poor execution e ciency. In such languages the computation consists of many small threads which are created dynamically and synchronized implicitly. In order to minimize the overhead of these operations, we propose ahybrid execution model which dynamically adapts to runtime data layout, providing both sequential e ciency and low overhead parallel execution. This model uses separately optimized sequential and parallel versions of code. Sequential e ciency is obtained by dynamically coalescing threads via stack-based execution and parallel e ciency through latency hiding and cheap synchronization using heap-allocated activation frames. Novel aspects of the stack mechanism include handling return values for futures and executing forwarded messages (the responsibility to reply is passed along, like call/cc in Scheme) on the stack. In addition, the hybrid execution model is expressed entirely in C, and therefore is easily portable to many systems. Experiments with function-call intensive programs show that this model achieves sequential e ciency comparable to C programs. Experiments with regular and irregular application kernels on the CM-5

DATA TYPES A. Comparing Type Objects There has been as much confusion over type identity as there has been over object identity, although the type identity problem is usually referred to as the type equivalence problem [Aho86,s.6.3] [Wegbreit74] [Welsh77]. The type identity problem is to determine when two types are equal, so that type checking can be done in a programming language. 22 Algol-68 takes the point of view of "structural" equivalence, in which nonrecursive types that are built up from primitive types using the same type constructors in the same order should compare equal, while Ada takes the point of view of "name" equivalence, in which types are equivalent if and only if they have the same name. We will ignore the software engineering issues of which kind of type equivalence makes for better-engineered programs, and focus on the basic issue of type equivalence itself. We note that if a type system offers the type TYPE---i.e., it offers first-class representations of typ...

Abstract not found

Abstract not found

Data parallel programming languages offer ease of programming and debugging and scalability of parallel programs to increasing numbers of processors. Unfortunately, the usefulness of these languages for non-scientific programmers and loosely coupled parallel machines is currently limited. In this paper, we present the composite tree model which seeks to provide greater flexibility via parallel data types, support for more general, hierachical parallelism, parallel control flow, and efficient execution on loosely coupled, coarse grained parallel machines such as workstation networks. The composite tree model is a new model of parallel programming based on merging data parallelism with object oriented programming languages, and can be implemented as a small set of extensions to any pure, static typed, object oriented programming language. 1 Introduction Data parallel programming achieves parallelism through the simultaneous execution of the same operation across a set of data [19]. In a...

Fine-grained concurrent object-oriented programming (COOP) models which provide a shared namespace, object-level concurrency and implicit dynamic thread creation can simplify the programming of irregular parallel applications on distributed memory machines. Unfortunately, COOP models are often perceived as inefficient and thus few complete applications have been implemented in COOP languages. In this paper, we study the implementation techniques required to obtain efficient parallel execution of fine-grained COOP languages using a complete, medium-sized protein molecular dynamics program, IC-CEDAR. We found that even given high data locality and achieving good sequential efficiency, an implementation that relies only on thread-oriented compiler and runtime optimizations and software multithreading fails to achieve parallel efficiency. We show that two major sources of overhead --- lack of processor-level data reuse and fine-grained threads for remote object accesses --- contribute to t...

Termite Scheme is a variant of Scheme intended for distributed computing. It offers a simple and powerful concurrency model, inspired by the Erlang programming language, which is based on a message-passing model of concurrency. Our system is well suited for building custom protocols and abstractions for distributed computation. Its open network model allows for the building of non-centralized distributed applications. The possibility of failure is reflected in the model, and ways to handle failure are available in the language. We exploit the existence of first class continuations in order to allow the expression of high-level concepts such as process migration. We describe the Termite model and its implications, how it compares to Erlang, and describe sample applications built with Termite. We conclude with a discussion of the current implementation and its performance.

Lisp has become the language of choice for many applications such as artificial intelligence programs or symbol manipulation. The original implementation of Lisp 1.5 was a concise, elegant statement of the semantics of the language. Although production Lisp systems have undergone significant development and evolution since Lisp 1.5, including the development of sophisticated compilers, there have been few significant theoretical improvements in the implementations of these systems. Most improvements, such as arrays or shallow-binding, have been made more for the sake of speed than for the sake of storage. A notable exception to this is the technique of tail recursion, which can save more than just stack space. We believe that more can be done to reduce the storage requirements of Lisp programs. Although in many instances, the Lisp programmer can reduce the storage requirements of his program by deleting unneeded pointers as soon as possible, there is nothing he can do about systematic ...