Region-based memory management for Mercury programs

Region-based memory management (RBMM) is a form of compile time memory management, well-known from the functional programming world. In this paper we describe our work on implementing RBMM for the logic programming language Mercury. One interesting point about Mercury is that it is designed with strong type, mode, and determinism systems. These systems not only provide Mercury programmers with several direct software engineering benefits, such as self-documenting code and clear program logic, but also give language implementors a large amount of information that is useful for program analyses. In this work, we make use of this information to develop program analyses that determine the distribution of data into regions and transform Mercury programs by inserting into them the necessary region operations. We prove the correctness of our program analyses and transformation. To execute the annotated programs, we have implemented runtime support that tackles the two main challenges posed by backtracking. First, backtracking can require regions removed during forward execution to be "resurrected"; and second, any memory allocated during a computation that has been backtracked over must be recovered promptly and without waiting for the regions involved to come to the end of their life. We describe in detail our solution of both these problems. We study in detail how our RBMM system performs on a selection of benchmark programs, including some well-known difficult cases for RBMM. Even with these difficult cases, our RBMM-enabled Mercury system obtains clearly faster runtimes for 15 out of 18 benchmarks compared to the base Mercury system with its Boehm runtime garbage collector, with an average runtime speedup of 24%, and an average reduction in memory requirements of 95%. In fact, our system achieves optimal memory consumption in some programs.Comment: 74 pages, 23 figures, 11 tables. A shorter version of this paper, without proofs, is to appear in the journal Theory and Practice of Logic Programming (TPLP

More Precise Region-Based Memory Management for Mercury Programs ⋆

Abstract. Dividing the heap memory of programs into regions is the starting point of region-based memory management. In our existing work of enabling region-based memory management for Mercury, a program analysis was used to distribute data over the regions. An important goal of the analysis is to decide which program variables should end up in the same region. For a popular class of programs, it covetously puts program variables in the same region, while more memory could have been reused if they had been kept in separate ones. In this paper we define a new refined region analysis that is keen to keep program variables in separate regions by taking into account the different execution paths of a procedure. With the more precise, path-sensitive analysis we can reduce the memory footprint for several programs.

Region-based memory management for Mercury programs. Part 1: Region analysis and transformation

Region-based memory management is a technique to do compile-time memory management based on the idea of dividing the heap memory into different regions such that, at runtime, memory can be reclaimed automatically by destroying regions in their entirety. This report contains a static region analysis for the logic programming language Mercury. We define region points-to graphs, which represent the locations of terms and the sharing among them, to model the partitioning of the memory used by a program into separate regions. The static analysis starts with a region points-to analysis that determines the different regions in the program. We then compute the liveness of the regions by a region liveness analysis. Finally, a program transformation adds sufficient region annotations to the program for region support. In this report we also give the correctness proofs for the analysis, so that the safety of memory accesses can be guaranteed. The implementation of the runtime support for region-based memory management in the Mercury compiler will be described in a second report.nrpages: 32status: publishe