Proceedings 20th IEEE International Parallel & Distributed Processing Symposium, 2006
One of the most promising applications of Aspect Oriented Programming (AOP) is the area of fault ... more One of the most promising applications of Aspect Oriented Programming (AOP) is the area of fault tolerance and recovery. In traditional programming languages, error handling code must be closely interwoven with program logic. AOP allows the programmer to take a more modular approach-error handling code can be woven into the code by expressing it as an aspect. One major impediment to handling error code in this way is that while errors are a dynamic, runtime property, most research on AOP has focused on static properties. In this paper, we propose a method for handling a variety of run-time faults as dynamic aspects. First, we separate fault handling into two different notions: fault determination, or the discovery of faults within a program, and and fault recovery, or the logic used to recover from a fault. Our position is that fault determination should be expressed as dynamic aspects. We propose a system, called Rescue, that exposes underlying features of the virtual machine in order to express faults as variety of run-time constraints. We show how our methodology can be used to address several of the flaws in state of the art fault fault handling techniques. This includes their limitations in handling parallel and distributed faults, their obfuscated nature and their overly simplistic notion of what a "fault" actually may comprise. 1
26th IEEE International Real-Time Systems Symposium (RTSS'05)
We present a new concurrency control abstraction for real-time systems called preemptible atomic ... more We present a new concurrency control abstraction for real-time systems called preemptible atomic regions (PARs). PARs a transactional mechanism that improves upon lock-based mutual exclusion in several ways. First, and foremost, PARs provide strong correctness guarantees. Any sequence of operations declared atomic will not suffer interference from other threads, even in the presence of programmer errors. In spite of this, PARs can be preempted by high priority tasks; this is essential to the minimization of blocking times. We have implemented PARs in a uniprocessor real-time Java virtual machine and evaluated their utility on a number of programs. The results suggest that programs that use PARs, depending on their semantics, can run faster and experience less jitter than those that use locks.
Proceedings of the 2006 workshop on Memory system performance and correctness - MSPC '06, 2006
Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programm... more Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programming languages. However, researchers have not considered the semantics of transactions with respect to a memory model weaker than sequential consistency. The details of such semantics are more subtle than many people realize, and the interaction between compiler transformations and transactions could produce behaviors that many people find surprising. A language's memory model, which determines these interactions, must clearly indicate which behaviors are legal, and which are not. These design decisions affect both the idioms that are useful for designing concurrent software and the compiler transformations that are legal within the language. Cases where semantics are more subtle than people expect include the actual meaning of both strong and weak atomicity; correct idioms for thread safe lazy initialization; compiler transformations of transactions that touch only thread local memory; and whether there is a well-defined notion for transactions that corresponds to the notion of correct and incorrect use of synchronization in Java. Open questions for a high-level memory-model that includes transactions involve both issues of isolation and ordering.
Java has integrated multithreading to a far greater extent than most programming languages. It is... more Java has integrated multithreading to a far greater extent than most programming languages. It is also one of the only languages that specifies and requires safety guarantees for improperly synchronized programs. It turns out that understanding these issues is far more subtle and difficult than was previously thought. The existing specification makes guarantees that prohibit standard and proposed compiler optimizations; it also omits guarantees that are necessary for safe execution of much existing code. Some guarantees that are made (e.g., type safety) raise tricky implementation issues when running unsynchronized code on SMPs with weak memory models.
One of the goals of the designers of the Java programming language was that multithreaded program... more One of the goals of the designers of the Java programming language was that multithreaded programs written in Java would have consistent and well-defined behavior. This would allow Java programmers to understand how their programs might behave; it would also allow Java platform architects to develop their platforms in a flexible and ecient way, while still ensuring that Java programs ran on them correctly. Unfortunately, Java's original memory model, which de- scribed the way in which Java threads interact through mem- ory, was not defined in a way that allowed programmers and architects to understand the requirements for a Java system. As part of Java Specification Request (JSR) 133 (7), a new memory model has been defined for Java. This paper out- lines how the requirements for a new memory model were established, and what those requirements are. It does not outline the model itself; it merely provides a rationale.
This paper describes the new Java memory model, which has been revised as part of Java 5.0. The m... more This paper describes the new Java memory model, which has been revised as part of Java 5.0. The model specifies the legal behaviors for a multithreaded program; it defines the semantics of multithreaded Java programs and partially determines legal implementations of Java virtual machines and compilers.The new Java model provides a simple interface for correctly synchronized programs -- it guarantees sequential consistency to data-race-free programs. Its novel contribution is requiring that the behavior of incorrectly synchronized programs be bounded by a well defined notion of causality. The causality requirement is strong enough to respect the safety and security properties of Java and weak enough to allow standard compiler and hardware optimizations. To our knowledge, other models are either too weak because they do not provide for sufficient safety/security, or are too strong because they rely on a strong notion of data and control dependences that precludes some standard compile...
Proceedings of the 2001 joint ACM-ISCOPE conference on Java Grande - JGI '01, 2001
Java has integrated multithreading to a far greater extent than most programming languages. It is... more Java has integrated multithreading to a far greater extent than most programming languages. It is also one of the only languages that specifies and requires safety guarantees for improperly synchronized programs. It turns out that understanding these issues is far more subtle and difficult than was previously thought. The existing specification makes guarantees that prohibit standard and proposed compiler optimizations; it also omits guarantees that are necessary for safe execution of much existing code. Some guarantees that are made (e.g., type safety) raise tricky implementation issues when running unsynchronized code on SMPs with weak memory models. This paper reviews those issues. It proposes a new core semantics for Java that allows for aggressive compiler optimization and addresses the safety and multithreading issues. Due to space constraints, certain side issues are addressed only in the full version of the semantics [8].
Proceedings of the ACM 1999 conference on Java Grande - JAVA '99, 1999
The Java memory model described in Chapter 17 of the Java Language Specification gives constraint... more The Java memory model described in Chapter 17 of the Java Language Specification gives constraints on how threads interact through memory. The Java memory model is hard to interpret and poorly understood; it imposes constraints that prohibit common compiler optimizations and are expensive to implement on existing hardware. At least one shipping optimizing Java compiler violates the constraints of the existing Java memory model. These issues are particularly important for high-performance Java applications, since they are more likely to use and need aggressive optimizing compilers and parallel processors. In addition, programming idioms used by some programmers and used within Sun's Java Development Kit is not guaranteed to be valid according the existing Java memory model. This paper reviews these issues and suggests replacement memory models for Java.
Abstract. With the advent of modern, multithreaded programming languages, it has become vitally i... more Abstract. With the advent of modern, multithreaded programming languages, it has become vitally important to describe in a clear and understandable way how threads interact through memory. The existing Java Memory Model is fundamen-tally broken; the process of creating an appropriate replacement has demonstrated exactly how deeply complex these issues can be. A formal specification [MP01a] of a replacement memory model is being de-veloped as part of the Java Community Process. As part of that e ort, we have developed a simulator that reflects the current version of this model. This simulator has proved invaluable in this e ort and will be an important tool for those trying to understand the final model.
Proceedings 20th IEEE International Parallel & Distributed Processing Symposium, 2006
One of the most promising applications of Aspect Oriented Programming (AOP) is the area of fault ... more One of the most promising applications of Aspect Oriented Programming (AOP) is the area of fault tolerance and recovery. In traditional programming languages, error handling code must be closely interwoven with program logic. AOP allows the programmer to take a more modular approach-error handling code can be woven into the code by expressing it as an aspect. One major impediment to handling error code in this way is that while errors are a dynamic, runtime property, most research on AOP has focused on static properties. In this paper, we propose a method for handling a variety of run-time faults as dynamic aspects. First, we separate fault handling into two different notions: fault determination, or the discovery of faults within a program, and and fault recovery, or the logic used to recover from a fault. Our position is that fault determination should be expressed as dynamic aspects. We propose a system, called Rescue, that exposes underlying features of the virtual machine in order to express faults as variety of run-time constraints. We show how our methodology can be used to address several of the flaws in state of the art fault fault handling techniques. This includes their limitations in handling parallel and distributed faults, their obfuscated nature and their overly simplistic notion of what a "fault" actually may comprise. 1
26th IEEE International Real-Time Systems Symposium (RTSS'05)
We present a new concurrency control abstraction for real-time systems called preemptible atomic ... more We present a new concurrency control abstraction for real-time systems called preemptible atomic regions (PARs). PARs a transactional mechanism that improves upon lock-based mutual exclusion in several ways. First, and foremost, PARs provide strong correctness guarantees. Any sequence of operations declared atomic will not suffer interference from other threads, even in the presence of programmer errors. In spite of this, PARs can be preempted by high priority tasks; this is essential to the minimization of blocking times. We have implemented PARs in a uniprocessor real-time Java virtual machine and evaluated their utility on a number of programs. The results suggest that programs that use PARs, depending on their semantics, can run faster and experience less jitter than those that use locks.
Proceedings of the 2006 workshop on Memory system performance and correctness - MSPC '06, 2006
Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programm... more Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programming languages. However, researchers have not considered the semantics of transactions with respect to a memory model weaker than sequential consistency. The details of such semantics are more subtle than many people realize, and the interaction between compiler transformations and transactions could produce behaviors that many people find surprising. A language's memory model, which determines these interactions, must clearly indicate which behaviors are legal, and which are not. These design decisions affect both the idioms that are useful for designing concurrent software and the compiler transformations that are legal within the language. Cases where semantics are more subtle than people expect include the actual meaning of both strong and weak atomicity; correct idioms for thread safe lazy initialization; compiler transformations of transactions that touch only thread local memory; and whether there is a well-defined notion for transactions that corresponds to the notion of correct and incorrect use of synchronization in Java. Open questions for a high-level memory-model that includes transactions involve both issues of isolation and ordering.
Java has integrated multithreading to a far greater extent than most programming languages. It is... more Java has integrated multithreading to a far greater extent than most programming languages. It is also one of the only languages that specifies and requires safety guarantees for improperly synchronized programs. It turns out that understanding these issues is far more subtle and difficult than was previously thought. The existing specification makes guarantees that prohibit standard and proposed compiler optimizations; it also omits guarantees that are necessary for safe execution of much existing code. Some guarantees that are made (e.g., type safety) raise tricky implementation issues when running unsynchronized code on SMPs with weak memory models.
One of the goals of the designers of the Java programming language was that multithreaded program... more One of the goals of the designers of the Java programming language was that multithreaded programs written in Java would have consistent and well-defined behavior. This would allow Java programmers to understand how their programs might behave; it would also allow Java platform architects to develop their platforms in a flexible and ecient way, while still ensuring that Java programs ran on them correctly. Unfortunately, Java's original memory model, which de- scribed the way in which Java threads interact through mem- ory, was not defined in a way that allowed programmers and architects to understand the requirements for a Java system. As part of Java Specification Request (JSR) 133 (7), a new memory model has been defined for Java. This paper out- lines how the requirements for a new memory model were established, and what those requirements are. It does not outline the model itself; it merely provides a rationale.
This paper describes the new Java memory model, which has been revised as part of Java 5.0. The m... more This paper describes the new Java memory model, which has been revised as part of Java 5.0. The model specifies the legal behaviors for a multithreaded program; it defines the semantics of multithreaded Java programs and partially determines legal implementations of Java virtual machines and compilers.The new Java model provides a simple interface for correctly synchronized programs -- it guarantees sequential consistency to data-race-free programs. Its novel contribution is requiring that the behavior of incorrectly synchronized programs be bounded by a well defined notion of causality. The causality requirement is strong enough to respect the safety and security properties of Java and weak enough to allow standard compiler and hardware optimizations. To our knowledge, other models are either too weak because they do not provide for sufficient safety/security, or are too strong because they rely on a strong notion of data and control dependences that precludes some standard compile...
Proceedings of the 2001 joint ACM-ISCOPE conference on Java Grande - JGI '01, 2001
Java has integrated multithreading to a far greater extent than most programming languages. It is... more Java has integrated multithreading to a far greater extent than most programming languages. It is also one of the only languages that specifies and requires safety guarantees for improperly synchronized programs. It turns out that understanding these issues is far more subtle and difficult than was previously thought. The existing specification makes guarantees that prohibit standard and proposed compiler optimizations; it also omits guarantees that are necessary for safe execution of much existing code. Some guarantees that are made (e.g., type safety) raise tricky implementation issues when running unsynchronized code on SMPs with weak memory models. This paper reviews those issues. It proposes a new core semantics for Java that allows for aggressive compiler optimization and addresses the safety and multithreading issues. Due to space constraints, certain side issues are addressed only in the full version of the semantics [8].
Proceedings of the ACM 1999 conference on Java Grande - JAVA '99, 1999
The Java memory model described in Chapter 17 of the Java Language Specification gives constraint... more The Java memory model described in Chapter 17 of the Java Language Specification gives constraints on how threads interact through memory. The Java memory model is hard to interpret and poorly understood; it imposes constraints that prohibit common compiler optimizations and are expensive to implement on existing hardware. At least one shipping optimizing Java compiler violates the constraints of the existing Java memory model. These issues are particularly important for high-performance Java applications, since they are more likely to use and need aggressive optimizing compilers and parallel processors. In addition, programming idioms used by some programmers and used within Sun's Java Development Kit is not guaranteed to be valid according the existing Java memory model. This paper reviews these issues and suggests replacement memory models for Java.
Abstract. With the advent of modern, multithreaded programming languages, it has become vitally i... more Abstract. With the advent of modern, multithreaded programming languages, it has become vitally important to describe in a clear and understandable way how threads interact through memory. The existing Java Memory Model is fundamen-tally broken; the process of creating an appropriate replacement has demonstrated exactly how deeply complex these issues can be. A formal specification [MP01a] of a replacement memory model is being de-veloped as part of the Java Community Process. As part of that e ort, we have developed a simulator that reflects the current version of this model. This simulator has proved invaluable in this e ort and will be an important tool for those trying to understand the final model.
Uploads
Papers by JEREMY MANSON