Aspect-oriented programming (AOP) is a technique for improving separation of concerns in software design and implementation. AOP works by providing explicit mechanisms for capturing the structure of crosscutting concerns. This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way. It works with AspectJ, a seamless aspect-oriented extension to the Java(tm) programming language, and with AspectC, an aspect-oriented extension to C in the style of AspectJ. It also includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.

Aspect-oriented programming

Aspect] is a simple and practical aspect-oriented extension to Java With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

An overview of AspectJ

AspectJ? is a simple and practical aspect-oriented extension to Java?. With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, join points are well-defined points in the execution of the program; pointcuts are collections of join points; advice are special method-like constructs that can be attached to pointcuts; and aspects are modular units of crosscutting implementation, comprising pointcuts, advice, and ordinary Java member declarations. AspectJ code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes. Several examples show that AspectJ is powerful, and that programs written using it are easy to understand.

/pdf/an-overview-of-aspectj-159di7yz43.pdf

An Overview of AspectJ

Transactional Memory (TM) is emerging as a promising technology to simplify parallel programming. While several TM systems have been proposed in the research literature, we are still missing the tools and workloads necessary to analyze and compare the proposals. Most TM systems have been evaluated using microbenchmarks, which may not be representative of any real-world behavior, or individual applications, which do not stress a wide range of execution scenarios. We introduce the Stanford Transactional Application for Multi-Processing (STAMP), a comprehensive benchmark suite for evaluating TM systems. STAMP includes eight applications and thirty variants of input parameters and data sets in order to represent several application domains and cover a wide range of transactional execution cases (frequent or rare use of transactions, large or small transactions, high or low contention, etc.). Moreover, STAMP is portable across many types of TM systems, including hardware, software, and hybrid systems. In this paper, we provide descriptions and a detailed characterization of the applications in STAMP. We also use the suite to evaluate six different TM systems, identify their shortcomings, and motivate further research on their performance characteristics.

/pdf/stamp-stanford-transactional-applications-for-multi-5ascbp3x5h.pdf

STAMP: Stanford Transactional Applications for Multi-Processing

In this paper we consider productivity challenges for parallel programmers and explore ways that parallel language design might help improve end-user productivity. We offer a candidate list of desirable qualities for a parallel programming language, and describe how these qualities are addressed in the design of the Chapel language. In doing so, we provide an overview of Chapel's features and how they help address parallel productivity. We also survey current techniques for parallel programming and describe ways in which we consider them to fall short of our idealized productive programming model.

/pdf/parallel-programmability-and-the-chapel-language-3fa3iypnkj.pdf

Parallel Programmability and the Chapel Language

Recent integrated CPU-GPU processors like Intel's Broadwell and AMD's Kaveri support hardware CPU-GPU shared virtual memory, atomic operations, and memory coherency. This enables fine-grained CPU-GPU work-stealing, but architectural differences between the CPU and GPU hurt the performance of traditionally-implemented work-stealing on such processors. These architectural differences include different clock frequencies, atomic operation costs, and cache and shared memory latencies. This paper describes a preliminary implementation of our work-stealing scheduler, Libra, which includes techniques to deal with these architectural differences in integrated CPU-GPU processors. Libra's affinity-aware techniques achieve significant performance gains over classically-implemented work-stealing. We show preliminary results using a diverse set of nine regular and irregular workloads running on an Intel Broadwell Core-M processor. Libra currently achieves up to a 2× performance improvement over classical work-stealing, with a 20% average improvement.

Affinity-aware work-stealing for integrated CPU-GPU processors

Big data analytics requires high programmer productivity and high performance simultaneously on large-scale clusters. However, current big data analytics frameworks (e.g. Apache Spark) have prohibitive runtime overheads since they are library-based. We introduce a novel auto-parallelizing compiler approach that exploits the characteristics of the data analytics domain such as the map/reduce parallel pattern and is robust, unlike previous auto-parallelization methods. Using this approach, we build High Performance Analytics Toolkit (HPAT), which parallelizes high-level scripting (Julia) programs automatically, generates efficient MPI/C++ code, and provides resiliency. Furthermore, it provides automatic optimizations for scripting programs, such as fusion of array operations. Thus, HPAT is 369x to 2033x faster than Spark on the Cori supercomputer and 20x to 256x times on Amazon AWS.

HPAT: High Performance Analytics with Scripting Ease-of-Use

Techniques for improved transactional memory management are described. In one embodiment, for example, an apparatus may comprise a processor element, an execution component for execution by the processor element to concurrently execute a software transaction and a hardware transaction according to a transactional memory process, a tracking component for execution by the processor element to activate a global lock to indicate that the software transaction is undergoing execution, and a finalization component for execution by the processor element to commit the software transaction and deactivate the global lock when execution of the software transaction completes, the finalization component to abort the hardware transaction when the global lock is active when execution of the hardware transaction completes. Other embodiments are described and claimed.

Transactional memory management techniques

A machine-learning decision system includes an online decision system and an offline decision system. The online decision system produces a first time slice-specific decision output corresponding to a first time slice based on one or more situational inputs received in the first time slice. The offline decision system produces a second Lime slice-specific decision output corresponding to the first time slice based on one or more situational inputs received in the first time slice and in a plurality of subsequent time slices occurring after the first time slice. The system further includes an online training system that conducts negative-reinforcement training of the online decision system in response to a nonconvergence between the first and the second time slice-specific decision outputs.

Forward-looking machine learning for decision systems

An improved method for compiler support of garbage collection. Live reference data to support a garbage collection process are stored in null operation instructions (NOPs) of an instruction set within the native code. This allows the live reference information to be encoded near the call instruction and thus the information can be retrieved in constant time. This may decease the amount of processing resources required for garbage collection. The compiler determines which references are live at each call. The compiler may also determine the number of bits that may be used to store those references. In one embodiment the number of NOPs is sufficient to store the information. In an alternative embodiment, NOPs are artificially inserted to store the information. Because a sufficient number of NOPs are typically present anyway, the method of one embodiment of the present invention does not significantly increase the size of the code.

Tatiana Shpeisman

Papers

Affinity-aware work-stealing for integrated CPU-GPU processors

HPAT: High Performance Analytics with Scripting Ease-of-Use

Transactional memory management techniques

Forward-looking machine learning for decision systems

Method for providing garbage collection support