Papers by Jan-Willem Maessen
Towards a Safer Interaction with Transactional Memory by Tracking Object Visibility
Lately there has been an increasing interest in Transactional Memory (TM), a programming API that... more Lately there has been an increasing interest in Transactional Memory (TM), a programming API that helps programmers writing scalable concurrent programs using sequential code. It is well known that writing concurrent programs using locks is a difficult task: coarse grained locking results in poor performance, and fine grained locking introduces the risk of deadlocking, and makes program’s maintenance difficult. With TM, the programmer only specifies what is required to be executed atomically, without worrying about the synchronization required to achieve this task. There are suggested implementations for TM both in hardware (HTM) and software (STM). While HTM is much faster than STM, it also has more limitations than STM does, and therefore it is not likely that we will have a widely available TM that is implemented purely in hardware in the near future. While STM can compensate for most of the HTM limitations, it imposes a new difficulty on the programmer: STM does not allow concur...
Simplifying Parallel List Traversal Simplifying Parallel List Traversal
Computations described using Bird's constructive algebra of lists are nicely amenable to para... more Computations described using Bird's constructive algebra of lists are nicely amenable to parallel implementation. Indeed , by using higher-order functions, ordered list traversals such as foldl and foldr can be expressed as unordered reductions. Based on this observation, a set of optimizations have been developed for list traversals in the parallel Haskell (pH) compilerr12]. These optimizations are inspired by, and partially subsume, earlier work on the optimization of sequential list traversal. 1 Introduction Lists are a basic computational \glue" in many functional languages. They are easily expressed and understood by programmers, and ooer a compact notation for representing collections of data. The functional language Haskell 7] is no exception to this rule, and in fact encourages or even requires the use of lists to express certain sorts of computation. Functional languages also encourage a compositional coding style. This causes lists to be used extensively as interm...
Proceedings of the 2001 ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering, 2001
¢¡ ¤£ ¦¥ ¨ § © ! #" $ % ¦ & ' (£ )' ¡ 0' 21 3 ) 54 3 5 ¦ § &¡ 76 5 &© 8" 9 § @£ ¦¥ 0A 21 7 B C B¡... more ¢¡ ¤£ ¦¥ ¨ § © ! #" $ % ¦ & ' (£ )' ¡ 0' 21 3 ) 54 3 5 ¦ § &¡ 76 5 &© 8" 9 § @£ ¦¥ 0A 21 7 B C B¡ ¨D fk l mD n ' § t¡ y£ ¦ 5 o© ¦ Bh p 5£ qe y 9 r p © (' )' 21 3£ ¦p § t¡ ¨ © (' x © ( § tx ¨p © c£ C B£ ¦ § 6 B¡ s ve 3¡ x § 6 6 C¥ 7 &6 Ct v© qh U' o6 &' ( ¦ 56 5£ o1 ¨© ¦ A r' Bh p ' !" qD np &r &p u' 2 C B£ ¦ § ' 2¡ ¨© & 7 B¡ 54 ¨ x § ¡ ¨ s¥ ¨' i" 06 &' v ¨ s6 &' 2¡ y£ C B § t¡ ¨ § ¡ 7A p t' !" qD p &r 2 &p v' 5 C B£ ¦ § ' ¡ 7© 96 ! ¡ %d H' 2 3£ ¦ § x § tj
Lecture Notes in Computer Science, 1996
Proceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel programming, 2008
Transactional Memory (TM) is on its way to becoming the programming API of choice for writing cor... more Transactional Memory (TM) is on its way to becoming the programming API of choice for writing correct, concurrent, and scalable programs. Hardware TM (HTM) implementations are expected to be significantly faster than pure software TM (STM); however, full hardware support for true closed and open nested transactions is unlikely to be practical. This paper presents a novel mechanism, the split hardware transaction (SpHT), that uses minimal software support to combine multiple segments of an atomic block, each executed using a separate hardware transaction, into one atomic operation. The idea of segmenting transactions can be used for many purposes, including nesting, local retry, orElse, and user-level thread scheduling; in this paper we focus on how it allows linear closed and open nesting of transactions. SpHT overcomes the limited expressive power of best-effort HTM while imposing overheads dramatically lower than STM and preserving useful guarantees such as strong atomicity provided by the underlying HTM.
ACM SIGPLAN Notices, 2000
This paper describes alternative memory semantics for Java programs using an enriched version of ... more This paper describes alternative memory semantics for Java programs using an enriched version of the Commit/Reconcile/Fence (CRF) memory model [16]. It outlines a set of reasonable practices for safe multithreaded programming in Java. Our semantics allow a number of optimizations such as load reordering that are currently prohibited. Simple thread-local algebraic rules express the effects of optimizations at the source or bytecode level. The rules focus on reordering source-level operations; they yield a simple dependency analysis algorithm for Java. An instruction-by-instruction translation of Java memory operations into CRF operations captures thread interactions precisely. The fine-grained synchronization of CRF means the algebraic rules are easily derived from the translation. CRF can be mapped directly to a modern architecture, and is thus a suitable target for optimizing memory coherence during code generation.
S : An Implicitly Parallel -Calculus With Recursive Bindings
S extends the -calculus with recursive bindings, barriers, and updatable memory cells with synchr... more S extends the -calculus with recursive bindings, barriers, and updatable memory cells with synchronized operations. The calculus can express both deterministic and nondeterministic computations. It is designed to be useful for reasoning about compiler optimizations and thus allows reductions anywhere, even inside 's. Despite the presence of side effects, the calculus retains fine-grained, implicit parallelism and non-strict functions: there is no global, sequentializing store. Barriers, for sequencing, capture a robust notion of termination. Although S was developed as a foundation for the parallel functional languages pH and Id, we believe that barriers give it wider applicability---to sequential, explicitly parallel and concurrent languages. In this paper we describe the S -calculus and its properties, based on a notion of observable information in a term. We also describe reduction strategies to compute maximal observable information even in the presence of unbounded nondeter...
Electronic Notes in Theoretical Computer Science
λS extends the λ-calculus with recursive bindings, barriers, and updatable memory cells with sync... more λS extends the λ-calculus with recursive bindings, barriers, and updatable memory cells with synchronized operations. The calculus can express both deterministic and nondeterministic computations. It is designed to be useful for reasoning about compiler optimizations and thus allows reductions anywhere, even inside λ's. Despite the presence of side effects, the calculus retains fine-grained, implicit parallelism and non-strict functions: there is no global, sequentializing store. Barriers, for sequencing, capture a robust notion of termination. Although λS was developed as a foundation for the parallel functional languages pH and Id, we believe that barriers give it wider applicability — to sequential, explicitly parallel and concurrent languages. In this paper we describe the λS-calculus and its properties, based on a notion of observable information in a term. We also describe reduction strategies to compute maximal observable information even in the presence of unbounded nond...
Computation Structures Group Memo 377-1
The semantics of kernel pH are defined in the form of a parallel, normalizing interpreter.
Bottom Extraction Factoring error handling out of functional programs
ABSTRACT Many utility functions in a functional programming language consist of just a few lines ... more ABSTRACT Many utility functions in a functional programming language consist of just a few lines of code. They are written with the expectation that they will be inlined and heavily optimized. For many of these functions, the size of the function being inlined is dominated by the size of code required to signal an error if the inputs are inconsistent. In this paper we describe bottom extraction, a simple technique which mitigates this problem. Using a combination of type information and strictness information, we can easily identify expressions which are devoted to error handling (semantically bottom). Such a bottom expression is enlarged to encompass as much code as possible by a set of local rules. Bottom regions are extracted and hoisted to the top level of the program. Bottom extraction greatly reduces code bloat in the presence of inlining by reducing the size of inlined code. In addition, it provides a simple and fast test to identify error handling code in the rest of the compiler, enabl...
Simplifying parallel list traversal
ABSTRACT Computations described using Bird's constructive algebra of lists are nicely ame... more ABSTRACT Computations described using Bird's constructive algebra of lists are nicely amenable to parallel implementation. Indeed, by using higher-order functions, ordered list traversals such as foldl and foldr can be expressed as unordered reductions. Based on this observation, a set of optimizations have been developed for list traversals in the parallel Haskell (pH) compiler[12]. These optimizations are inspired by, and partially subsume, earlier work on the optimization of sequential list traversal. 1 Introduction Lists are a basic computational "glue" in many functional languages. They are easily expressed and understood by programmers, and offer a compact notation for representing collections of data. The functional language Haskell [7] is no exception to this rule, and in fact encourages or even requires the use of lists to express certain sorts of computation. Functional languages also encourage a compositional coding style. This causes lists to be used extensively as intermediate d...
ACM SIGPLAN Notices, 2004
Programs that manipulate physical quantities typically represent these quantities as raw numbers ... more Programs that manipulate physical quantities typically represent these quantities as raw numbers corresponding to the quantities' measurements in particular units (e.g., a length represented as a number of meters). This approach eliminates the possibility of catching errors resulting from adding or comparing quantities expressed in different units (as in the Mars Climate Orbiter error [11]), and does not support the safe comparison and addition of quantities of the same dimension. We show how to formulate dimensions and units as classes in a nominally typed object-oriented language through the use of statically typed metaclasses. Our formulation allows both parametric and inheritance poly-morphism with respect to both dimension and unit types. It also allows for integration of encapsulated measurement systems, dynamic conversion factors, declarations of scales (including nonlinear scales) with defined zeros, and nonconstant exponents on dimension types. We also show how to encap...
Lecture Notes in Computer Science, 1997
Fortress (Sun HPCS Language)
Encyclopedia of Parallel Computing, 2011
ACM SIGARCH Computer Architecture News, 2006
We present a novel framework for defining memory models in terms of two properties: thread-local ... more We present a novel framework for defining memory models in terms of two properties: thread-local Instruction Reordering axioms and Store Atomicity, which describes inter-thread communication via memory. Most memory models have the store atomicity property, and it is this property that is enforced by cache coherence protocols. A memory model with Store Atomicity is serializable; there is a unique global interleaving of all operations which respects the reordering rules. Our framework uses partially ordered execution graphs; one graph represents many instruction interleavings with identical behaviors. The major contribution of this framework is a procedure for enumerating program behaviors in any memory model with Store Atomicity. Using this framework, we show that address aliasing speculation introduces new program behaviors; we argue that these new behaviors should be permitted by the memory model specification. We also show how to extend our model to capture the behavior of non-ato...
Proceedings of the 2002 ACM SIGPLAN workshop on Haskell, 2002
The advantages of the Haskell programming language are rooted in its clean equational semantics. ... more The advantages of the Haskell programming language are rooted in its clean equational semantics. Those advantages evaporate as soon as programmers try to write simple iterative computations and discover that their code must be annotated with calls to seq in order to overcome space leaks introduced by lazy evaluation. The Eager Haskell compiler executes Haskell programs eagerly by default, i.e. , bindings and function arguments are evaluated before bodies. When resource bounds are exceeded, computation falls back and is restarted lazily. By using a hybrid of eager and lazy evaluation, we preserve the semantics of Haskell and yet permit efficient iteration.
The advantage of a non-strict, purely functional language such as Haskell lies in its clean equat... more The advantage of a non-strict, purely functional language such as Haskell lies in its clean equational semantics. However, lazy implementations of Haskell fall short: they cannot express tail recursion gracefully without annotation. We describe resource-bounded hybrid evaluation, a mixture of strict and lazy evaluation, and its realization in Eager Haskell. From the programmer's perspective, Eager Haskell is simply another implementation of Haskell with the same clean equational semantics. Iteration can be expressed using tail recursion, without the need to resort to program annotations. Under hybrid evaluation, computations are ordinarily executed in program order just as in a strict functional language. When particular stack, heap, or time bounds are exceeded, suspensions are generated for all outstanding computations. These suspensions are re-started in a demand-driven fashion from the root. The Eager Haskell compiler translates λ C , the compiler's intermediate representation, to efficient C code. We use an equational semantics for λ C to develop simple correctness proofs for program transformations, and connect actions in the run-time system to steps in the hybrid evaluation strategy. The focus of compilation is efficiency in the common case of straight-line execution; the handling of non-strictness and suspension are left to the run-time system. Several additional contributions have resulted from the implementation of hybrid evaluation. Eager Haskell is the first eager compiler to use a call stack. Our generational garbage collector uses this stack as an additional predictor of object lifetime. Objects above a stack watermark are assumed to be likely to die; we avoid promoting them. Those below are likely to remain untouched and therefore are good candidates for promotion. To avoid eagerly evaluating error checks, they are compiled into special bottom thunks, which are treated specially by the run-time system. The compiler identifies error handling code using a mixture of strictness and type information. This information is also used to avoid inlining error handlers, and to enable aggressive program transformation in the presence of error handling.
Electronic Notes in Theoretical Computer Science, 2007
We extend the notion of Store Atomicity [4] to a system with atomic transactional memory. This gi... more We extend the notion of Store Atomicity [4] to a system with atomic transactional memory. This gives a fine-grained graph-based framework for defining and reasoning about transactional memory consistency. The memory model is defined in terms of thread-local Instruction Reordering axioms and Store Atomicity, which describes inter-thread communication via memory. A memory model with Store Atomicity is serializable: there is a unique global interleaving of all operations which respects the reordering rules and serializes all the operations in a transaction together. We extend Store Atomicity to capture this ordering requirement by requiring dependencies which cross a transaction boundary to point in to the initiating instruction or out from the committing instruction. We sketch a weaker definition of transactional serialization which accounts for the ability to interleave transactional operations which touch disjoint memory. We give a procedure for enumerating the behaviors of a transactional program-noting that a safe enumeration procedure permits only one transaction to read from memory at a time. We show that more realistic models of transactional execution require speculative execution. We define the conditions under which speculation must be rolled back, and give criteria to identify which instructions must be rolled back in these cases.
The extensive use of lists in functional programming languages exacts a cost penalty for importan... more The extensive use of lists in functional programming languages exacts a cost penalty for important operations such as array construction. In addition, because lists are linear data structures, it is difficult to generate and traverse them efficiently in parallel given a purely-functional environment. Three common methods of traversal-left and right fold, and reduction-can be described in terms of map and reduce operations yielding higher-order functions; these higher-order functions can be represented entirely at compile time. This thesis examines this representation of list traversal, describes its implementation in the desugaring phase of the compiler for pH (an implicitly-parallel, mostly-functional dialect of the language Haskell). This approach to desugaring gives rise to a set of rules for compiling list comprehensions efficiently, and to a pair of functions unfold and synthesize which can be immediately eliminated if the lists they generate are traversed by folding or reduction.
PH Language Reference Manual, Version 1.0PRELIMINARY
… , MIT, 1995
ABSTRACT This document must be read in conjunction with the Haskell Report [2] since it describes... more ABSTRACT This document must be read in conjunction with the Haskell Report [2] since it describes only the extensions. In Section 2 we present the syntax extensions proper. In Section 3 we present some examples to give a flavor of the language. In Section 4 we present commentary and rationale. Future versions of this document will address topics such as loop pragmas, data and work distribution, etc. Background
Uploads
Papers by Jan-Willem Maessen