Hierarchical memory management for parallel programs

Abstract

An important feature of functional programs is that they are parallel by default. Implementing an efficient parallel functional language, however, is a major challenge, in part because the high rate of allocation and freeing associated with functional programs requires an efficient and scalable memory manager. In this paper, we present a technique for parallel memory management for strict functional languages with nested parallelism. At the highest level of abstraction, the approach consists of a technique to organize memory as a hierarchy of heaps, and an algorithm for performing automatic memory reclamation by taking advantage of a disentanglement property of parallel functional programs. More specifically, the idea is to assign to each parallel task its own heap in memory and organize the heaps in a hierarchy/tree that mirrors the hierarchy of tasks. We present a nested-parallel calculus that specifies hierarchical heaps and prove in this calculus a disentanglement property, which prohibits a task from accessing objects allocated by another task that might execute in parallel. Leveraging the disentanglement property, we present a garbage collection technique that can operate on any subtree in the memory hierarchy concurrently as other tasks (and/or other collections) proceed in parallel. We prove the safety of this collector by formalizing it in the context of our parallel calculus. In addition, we describe how the proposed techniques can be implemented on modern shared-memory machines and present a prototype implementation as an extension to MLton, a highperformance compiler for the Standard ML language. Finally, we evaluate the performance of this implementation on a number of parallel benchmarks.

Fairness in responsive parallelism

“…MLton is a mature, wholeprogram optimizing compiler which produces fast sequential code. The parallel extension to MLton was developed a number of years ago, but is being actively maintained and improved Raghunathan et al 2016]. Furthermore, MLton makes it easy to develop custom schedulers written directly in Standard ML with the use of its built-in library for user-level threads.…”

“…These developments have led to increased interest in languages and techniques for writing parallel programs. Many languages, libraries and systems have been developed, including NESL [Blelloch et al 1994], Cilk [Frigo et al 1998], Fork/Join Java [Lea 2000], Habanero Java [Imam and Sarkar 2014], TPL [Leijen et al 2009], TBB [Intel 2011], X10 [Charles et al 2005], parallel ML [Fluet et al 2011[Fluet et al , 2008Raghunathan et al 2016;Sivaramakrishnan et al 2014], and parallel Haskell [Keller et al 2010;Kuper et al 2014].…”

Correctness of a Concurrent Object Collector for Actor Languages

“…Local heaps have been used in the context of garbage collection to reduce the amount of synchronisation required before [1][2][3]13,15,24,31,34], where different threads have their own heap and share a global heap. However, only two of these have been proved correct.…”

Provably and practically efficient granularity control

“…Implicit threading seeks to make parallel programming easier by delegating certain tedious but important details, such as the scheduling of parallel tasks, to the compiler and the run-time system. There has been much work on specialized programming languages and language extensions for parallel systems, for various forms of implicit threading, including OpenMP [OpenMP Architecture Review Board 2008], Cilk [Frigo et al 1998], Fork/Join Java [Lea 2000], Habanero Java [Imam and Sarkar 2014], NESL [Blelloch et al 1994],TPL [Leijen et al 2009], TBB [Intel 2011], X10 [Charles et al 2005], parallel ML [Fluet et al 2011;Jagannathan et al 2010;Raghunathan et al 2016], and parallel Haskell [Chakravarty et al 2007;Keller et al 2010].…”