Optimizing hash-array mapped tries for fast and lean immutable JVM collections

Abstract

The data structures under-pinning collection API (e.g. lists, sets, maps) in the standard libraries of programming languages are used intensively in many applications.The standard libraries of recent Java Virtual Machine languages, such as Clojure or Scala, contain scalable and well-performing immutable collection data structures that are implemented as Hash-Array Mapped Tries (HAMTs). HAMTs already feature efficient lookup, insert, and delete operations, however due to their tree-based nature their memory footprints and the runtime performance of iteration and equality checking lag behind array-based counterparts. This particularly prohibits their application in programs which process larger data sets.In this paper, we propose changes to the HAMT design that increase the overall performance of immutable sets and maps. The resulting general purpose design increases cache locality and features a canonical representation. It outperforms Scala's and Clojure's data structure implementations in terms of memory footprint and runtime efficiency of iteration (1.3-6.7 x) and equality checking (3-25.4 x).

Towards a software product line of trie-based collections

“…HAMTs constitute the basis for purely functional collections that are incrementally constructed and may refer to the unaltered parts of previous states [11,20]. In previous work we introduced the Compressed Hash-Array Mapped Prefixtree (CHAMP) [28], a cache-oblivious and canonical HAMT variant that improves the runtime efficiency of iteration (1.3-6.7 x) and equality checking (3-25.4 x) over its predecessor, while at the same time reducing memory footprints.…”

“…Yet, a feature model allows for customization towards specific workloads (e.g., sparse vectors). For certain efficiency trade-offs it is important to distinguish between HAMT encodings which store dataAsLeafs and encodings which allow for mixedNodes internally [28]. We currently generate unordered set, map, and multi-map data structures based on the state-of-the-art HAMT variants: HAMT [3], CHAMP [28], and HHAMT [27].…”

“…For certain efficiency trade-offs it is important to distinguish between HAMT encodings which store dataAsLeafs and encodings which allow for mixedNodes internally [28]. We currently generate unordered set, map, and multi-map data structures based on the state-of-the-art HAMT variants: HAMT [3], CHAMP [28], and HHAMT [27]. The latter is a generalization of the former two and supports multiple heterogeneous payload categories simultaneously.…”

“…Depending on the feature configuration, order, sequence, and types of the elements in the array may differ. For example, these arrays can mix payload and sub-nodes in arbitrary order, or group elements per content category together [28]. We model this variability in array content as follows: A partition describes a typed sequence of elements that is limited to a size Range (lower and upper bounds).…”

“…A slice is the atomic unit, whereas a stripe joins two or more adjacent slices together. The two Direction values, forward or backward, allow advanced slice configurations that -similar to heap and stack-grow from separate fixed bases, to omit the necessity of dynamic partition boundary calculations [28].…”