Using Reified Types for Specialization

Generic code increases programmer productivity as it increases code reuse. For example, the LinkedList abstraction can be used in many contexts, from storing a list of numbers to storing representations of files on the disk. Unfortunately this comes at the expense of performance, as the generic code needs a common representation for all types. The common representation is usually a pointer to heap data. But for value types, such as integers, bytes and even value classes (see SIP-15) this leads to significant overheads, as they need to be allocated as objects on the heap and then pointed to, breaking data locality and adding an extra indirection. To overcome this performance loss, many programming languages and virtual machines perform code specialization, which creates a copy of the generic class for each value type and adapts the data representation. Scala does not require type parameters to be known at compile time, thus allowing truly-generic code to be generated. In this case, type information is not necessary and will not available in the generated bytecode. But this prohibits programmers from using specialized code from generic code, which might be desirable. Scala can overcome the loss of type information in generic classes by attaching types in so-called ClassTags (formerly known as Manifests). This information can be used to dispatch to the correct specialized class implementation, and can be made either as a compiler plugin or as a macro. Either implementation is fine, as long as the syntactic overhead is reasonable. For this project one should research what is the best implementation and prepare a set of benchmarks that clearly show the performance hit of dispatching based on the ClassTag

Serfs: Dynamically-Bound Parameterized Components

Parameterization is an effective technique for decoupling design decisions in software. Several languages such as C++ and Ada (and Java and C# more recently) offer language constructs for building parameterized software. Using template or generic constructs, one can postpone committing to specific design choices until the software system is ready for deployment. However, in cases where such choices are influenced by the execution environment, deployment time may not be late enough. Moreover, in the context of software systems that have to satisfy high availability constraints, or are long-running, changes in design choices may be warranted even after deployment. In this paper, we present a design pattern-based methodology for building parameterized components that support dynamic binding of parameters. Moreover, the methodology also supports dynamic re-binding of parameters in the event that such online change is required

Serfs: Dynamically-Bound Parameterized Components

Parameterization is an effective technique for decoupling design decisions in software. Several languages such as C++ and Ada (and Java and C# more recently) offer language constructs for building parameterized software. Using template or generic constructs, one can postpone committing to specific design choices until the software system is ready for deployment. However, in cases where such choices are influenced by the execution environment, deployment time may not be late enough. Moreover, in the context of software systems that have to satisfy high availability constraints, or are long-running, changes in design choices may be warranted even after deployment. In this paper, we present a design pattern-based methodology for building parameterized components that support dynamic binding of parameters. Moreover, the methodology also supports dynamic re-binding of parameters in the event that such online change is required

Compiling generics through user-directed type specialization

Compilation of polymorphic code through type erasure gives compact code but performance on primitive types is significantly hurt. Full specialization gives good performance, but at the cost of increased code size and compilation time. Instead we propose a mixed approach, which allows the programmer to decide what code to specialize. Our approach supports separate compilation, allows mixing of specialized and generic code, and gives very good results in practice

Better Generative Programming with Generic Aspects

Abstract. After a brief introduction to generative, generic, and aspect-oriented programming, we point out four key elements that appear in the definition of generative programming and that are addressed in this position paper from the perspective of distributed systems development. Then, based on a concrete RMI distribution example, we start motivating how the expressiveness power of generics and the crosscutting modularization power of aspects could be combined in order to achieve highly reusable generic aspects. We conclude by presenting how generic concern-oriented model transformations could help in providing the necessary information to aspect generators for automatically instantiating our generic aspects before weaving them into concrete applications

Miniboxing: An Encoding for Specialization

In the presence of parametric polymorphism, erasure-based languages such as Java and Scala handle primitives (boolean values, integers and floating point numbers) in a suboptimal way: in order to provide a uniform representation on the low level, all primitive values are stored in heap objects, in a process known as boxing. This leads to access overheads, wasteful usage of the heap space and broken cache locality. Specialization enables Scala to optimally handle primitive values in the context of generic classes, but this is done at the expense of duplicating classes up to 10 times for each type parameter, for each of the 9 Scala primitive types and heap objects. This prevents specialization of key classes in the Scala library, such as Function2, List, Map and so on. This project aims at testing the hypothesis that encoding several primitive types into a larger stack-based primitive type can maintain the performance of specialized code, while dramatically decreasing the generated bytecode size

The C++0x "Concepts" Effort

C++0x is the working title for the revision of the ISO standard of the C++ programming language that was originally planned for release in 2009 but that was delayed to 2011. The largest language extension in C++0x was "concepts", that is, a collection of features for constraining template parameters. In September of 2008, the C++ standards committee voted the concepts extension into C++0x, but then in July of 2009, the committee voted the concepts extension back out of C++0x. This article is my account of the technical challenges and debates within the "concepts" effort in the years 2003 to 2009. To provide some background, the article also describes the design space for constrained parametric polymorphism, or what is colloquially know as constrained generics. While this article is meant to be generally accessible, the writing is aimed toward readers with background in functional programming and programming language theory. This article grew out of a lecture at the Spring School on Generic and Indexed Programming at the University of Oxford, March 2010

The Java 5 Generics Compromise Orthogonality to Keep Compatibility

In response to a long-lasting anticipation by the Java community, version 1.5 of the Java 2 platform - referred to as Java 5 - introduced generic types and methods to the Java language. The Java 5 generics are a significant enhancement to the language expressivity because they allow straightforward composition of new generic classes from existing ones while reducing the need for a plethora of type casts. While the Java 5 generics are expressive, the chosen implementation method, type erasure, has triggered undesirable orthogonality violations. This paper identifies six cases of orthogonality violations in the Java 5 generics and demonstrates how these violations are mandated by the use of type erasure. The paper also compares the Java 5 cases of orthogonality violations to compatible cases in C# 2 and NextGen 2 and analyzes the trade-offs in the three approaches. The conclusion is that Java 5 users face new challenges: a number of generic type expressions are forbidden, while others that are allowed are left unchecked