Late data layout

Abstract

Values need to be represented differently when interacting with certain language features. For example, an integer has to take an object-based representation when interacting with erased generics, although, for performance reasons, the stack-based value representation is better. To abstract over these implementation details, some programming languages choose to expose a unified high-level concept (the integer) and let the compiler choose its exact representation and insert coercions where necessary. This pattern appears in multiple language features such as value classes, specialization and multi-stage programming: they all expose a unified concept which they later refine into multiple representations. Yet, the underlying compiler implementations typically entangle the core mechanism with assumptions about the alternative representations and their interaction with other language features. In this paper we present the Late Data Layout mechanism, a simple but versatile type-driven generalization that subsumes and improves the state-of-the-art representation transformations. In doing so, we make two key observations: (1) annotated types conveniently capture the semantics of using multiple representations and (2) local type inference can be used to consistently and optimally introduce coercions. We validated our approach by implementing three language features as Scala compiler extensions: value classes, specialization (using the miniboxing representation) and a simplified multi-stage programming mechanism.

Automating ad hoc data representation transformations

“…As necessary background for our approach, we review data representation transformations and, in particular, the Late Data Layout transformation mechanism [47], which we later extend to our Ad hoc Data Representation Transformation.…”

“…The Late Data Layout (LDL) mechanism [47] is the underlying transformation used in Scala to implement multiparameter value class inlining and to specialize classes using the miniboxed encoding [46]. It is a flexible and reliable mechanism, tested on thousands of lines of Scala code.…”

“…Yet, the first one is markedly better: it does not execute any coercions, compared to second definition, which executes two coercions regardless of the value of c. These subtle sub-optimalities can slow down program execution, increase the heap footprint and the bytecode size. The LDL paper [47] makes the following intuition-based conjecture: "in any given terminating execution trace through the transformed program, the number of coercions executed is minimal, for given sets of annotations introduced by the INJECT phase and transformations performed in the COM-MIT phase". An initial formalization and proof is sketched in [45].…”

“…If generics are unboxed and reified, the list type will be List[@unboxed Int]. The LDL paper [47] shows examples of both cases: when annotations are propagated inside generics and when they are not. The LDL mechanism adapts seamlessly to either case.…”

“…It may seem natural that the value t will be transformed to use the V representation type: first, converting from T to U and then from U to V. Unfortunately, the underlying mechanism, Late Data Layout [47], only allows values to undergo one representation change in the COERCE phase. Thus, to enable cascading scopes, we would have to either run the COERCE phase until a fixpoint or extend both the theory and the implementation to handle multiple conversions in a single run, neither of which is a straightforward extension.…”