Java's threads offer appropriate means either for parallel programming of SMPs or as target constructs when compiling add-on features (e.g. forall constructs, automatic parallelization, etc.) Unfortunately, Java does not provide elegant and straightforward mechanisms for parallel programming on distributed memory machines, like clusters of workstations. JavaParty transparently adds remote objects to Java purely by declaration while avoiding disadvantages of explicit socket communication, the programming overhead of RMI, and many disadvantages of the message-passing approach in general. JavaParty is specifically targeted towards and implemented on clusters of workstations. It hence combines Java-like programming and the concepts of distributed shared memory in heterogeneous networks.

Object-oriented distributed computing is becoming increasingly important for critical infrastructure in society. In standard object-oriented models, objects synchronize on method calls. These models may be criticized in the distributed setting for their tight coupling of communication and synchronization; network delays and instabilities may locally result in much waiting and even deadlock. The Creol model targets distributed objects by a looser coupling of method calls and synchronization. Asynchronous method calls and high-level local control structures allow local computation to adapt to network instability. Object variables are typed by interfaces, so communication with remote objects is independent from their implementation. The inheritance and subtyping relations are distinct in Creol. Interfaces form a subtype hierarchy, whereas multiple inheritance is used for code reuse at the class level. This paper presents the Creol syntax, operational semantics, and type system. It is shown that runtime type errors do not occur for well-typed programs.

Embedded specifications in object-oriented (OO) languages such as Eiffel and Sather are based on a rigorous approach towards validation, compatibility and reusability of sequential programs. The underlying method of "design-by-contract" is based on Hoare logic for which concurrency extensions exist. However concurrent OO languages are still in their infancy. They have inherently imperative facets, such as object identity, sharing, and synchronisation, which cannot be ignored in the semantics. Any marriage of objects and concurrency requires a trade-off in a space of intertwined qualities. This paper summarises our work on a type system, calculus and an operational model for concurrent objects in a minimal extension of the Eiffel and Sather languages (cSather). We omit concurrency control constructs and instead use assertions as synchronisation constraints for asynchronous functions. We show that this provides a framework in which subtyping and concurrency can coexist. 1 Introduction C...

80 implementations of the same set of requirements, created by 74 different programmers in various languages, are compared for several properties, such as run time, memory consumption, source text length, comment density, program structure, reliability, and the amount of effort required for writing them. The results indicate that, for the given programming problem, "scripting languages" (Perl, Python, Rexx, Tcl) are more productive than conventional languages. In terms of run time and memory consumption, they often turn out better than Java and not much worse than C or C++. In general, the differences between languages tend to be smaller than the typical differences due to different programmers within the same language. 2 CONTENTS Contents 1 On language comparisons 3 2 Origin of the programs 3 2.1 Non-script group: C, C++, Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Script group: Perl, Python, Rexx, Tcl . . . . . . . . . . . . . . . . . . . . . ....

In this paper, we describe the vision and the design of a programming environment, called Shangri-La, aimed at making future generations of packet-processing systems – multi-core, light-weight threaded hardware in general, and network processor (NP)-based systems in particular – as easily programmable as today’s workstations and servers. Our environment consists of: (1) a domainspecific programming language for specifying packetprocessing applications, (2) a compiler that incorporates profile-guided techniques for mapping packet-processing applications onto complex packet-processing system architectures, and (3) a run-time system that dynamically adapts resource allocations to create systems that are robust against attacks and that optimize performance and power consumption for the current network conditions. We justify our design and articulate the challenges in designing each of these components. 1.

On clusters and DMPs, locality of objects and threads and hence avoidance of network communication, are crucial for the application performance. We show that -- in certain situations -- an extension of known type inference mechanisms can be used to compute placement decisions that improve locality of threads and objects and hence reduce the application execution times. In addition to this general...

Abstract. Objects ’ state, intended as some abstraction over the value of fields, is always in the mind of a COOL (Concurrent Object-Oriented Language) programmer. In fact, as the state of an object changes so does its coordination behaviour. We introduce a language feature for expressing the notion of state in Java-like languages. The proposed feature takes the form of state class, a new kind of class, equipped with a static type and effect system guaranteeing that during the execution of a method on a receiver o: (1) Even though the state of o may vary through states with different parameters, no attempt will be made to access non-existing parameters, and (2) No method invoked on a receiver different from this may cause (through method calls on o) a change in the state of o. 1

classes have been omited for clarity. The methods are executed in the order in which they are numbered. pattern from [3], acting as the interface for all of its collaborators (Data Container, Merger Container, and Merger Sequence). It further serves to store partial results generated from one phase and used in another, such as the pivot array from the second phase of PSRS. The subphases for the last phase of PSRS are implemented using a second instance of the Method Sequence pattern, the Merger Sequence and Merger Facade objects. The remaining collaborators are instances of the Distributor pattern, discussed in Section 3. These objects implement the concurrency in the algorithm. The Method Sequence pattern in this example consists of the following methods: ffl sortPartitions() to implement the first phase. ffl getPivots() to implement the second phase. ffl partitionData() to implement the third phase. This method invokes the initialize() method on the Merger Container object. The merg...

Abstract: We introduce state classes, a construct to program objects that can be safely concurrently accessed. State classes model the notion of object’s state (intended as some abstraction over the value of fields) that plays a key role in concurrent object-oriented programming (as the state of an object changes, so does its coordination behavior). We show how state classes can be added to Java-like languages by presenting STATEJ, an extension of JAVA with state classes. The operational semantics of the state class construct is illustrated both at an abstract level, by means of a core calculus for STATEJ, and at a concrete level, by defining a translation from STATEJ into JAVA. 1

Four scripting languages are introduced shortly and their theoretical and purported characteristics are discussed and related to three more conventional programming languages.