Towards Regionbased Memory Management for Mercury Programs

1
Towards Region-based Memory Management for
Mercury Programs

• Quan Phan and Gerda Janssens
• DTAI Analysis group
• Katholieke Universiteit Leuven, Belgium
• CICLOPS 2006

2
Outline

• Introduction background
• The static RBMM analysis
• Prototype and experiments
• Future work

3
Memory management in logic programming

• Logic programming is declarative
• No procedural details
• No malloc/free for managing the heap
• Automatically recover memory
• Instant reclaiming
• Rely on backtracking
• Not enough deterministic survive shallow
  backtracking
• Runtime garbage collection
• Effectively recover, gt 90 the garbage on the
  heap
• Problem runtime overhead, time-unpredictable

4
Region-based Memory Management (RBMM)
Basic idea
The heap

• Heap different regions

X
.
.

• Terms distributed over regions

1
2
Y

• A region is released as a whole

.
3

.
Z
.
.
5
1. RBMM in LP

• An extensive research field in functional
  programming
• Mostly SML
• More recently C, Cyclone, Java
• For logic programming
• application to WAM-based Prolog by Henning
  Makholm Kostis Sagonas
• Focus runtime support for nondeterminism.

6
Mercury language

• Functional/logic programming language
• developed at Melbourne Univ.
• declarative AND efficient
• Explicit declarations types, modes, determinism
• Very useful in program analyses and optimisations

7
Mercury language

• Procedure
• predicate and a mode
• Superhomogeneous form
• explicit disjunctions
• goals reordered
• specialized unifications

- pred append( list(T)in, list(T)in,
list(T)out) is det. append(X, Y, Z) - ( X
gt , Z Y X gt Xe Xs, append(Xs,Y,Zs)
, Z lt Xe Zs ).
8
The algorithm

• Three phases
• Region points-to analysis
• build the memory model
• Region liveness analysis
• decide region lifetime
• Source-to-source transformation
• add creation and removal instructions

9
Term representation

• Region points-to analysis
• Which variables are in the same region?
• X Y or Y X
• OR term and subterm of the same type
• X _ Xs, type(X) type(Xs)

X Xe Xs
X
.
.
1
Xs
.
2

10
Region points-to graph

• Region points-to analysiss goal
• Produce region points-to graph
• One for each procedure
• Model the heap in terms of regions
• Node physical region
• Associated set of variables, stored in the region
• Directed edge
• A region contains references to another region
• Labelled by a type selector

11
Region points-to graph
(f, 1)
B

• A f(B, C)
• X Xe Xs

A
(f, 2)
C
X
.
.
1
Xs
.
2

(., 2)
(., 1)
X, Xs
Xe
12
Region points-to analysis

• Intraprocedural analysis
• process (specialized) unifications
• Interprocedural analysis
• deal with proceduce calls
• integrate the graph of the callee into that of
  the caller
• update the callers graph due to the effect of
  that call.

13
Region points-to analysis

• mode(in,in,out)
• append(X,Y,Z) -
• (
• (1) X gt ,
• (2) Z Y
• (3) X gt XeXs,
• (4) append(Xs,Y,Zs),
• (5) Z lt XeZs
• )

(., 2)
(., 2)
(., 1)
(., 1)
Z, Y, Zs
Xe
caller
Z
Z, Y
X
X, Xs
(.,2)
(., 2)
Y
Zs
Xs
(., 2)
(., 2)
(., 1)
(., 1)
Z, Y, Zs
Xe
X, Xs
callee
14
Live region analysis

• Live variable
• instantiated
• used in future
• Live region
• reachable from a live variable
• deadR
• regions that can be removed by a procedure
• bornR
• can be created

15
Region liveness for append
(., 2)
(., 2)
(R2)
(., 1)
(., 1)
Z, Y, Zs
(R3)
Xe
(R1)
X, Xs
mode(i, i, o) append(X,Y,Z) - ( (1) X gt
, (2) Z Y (3) X gt XeXs, (4)
append(Xs,Y,Zs), (5) Z lt XeZs )
deadR R1, bornR
16
Program transformation

• For procedure p, in an execution path
• Region creation create R
• when R becomes live at i
• NOT live before i but live after i
• li does NOT create R
• A caller of p does NOT create R

17
Program transformation

• Region removal remove R
• when R ceases to be live at i
• live before i but NOT live after i
• NOT removed by li
• p allowed to remove R
• OR
• R live after i, but not before j, j is after i in
  the execution path

18
(., 2)
(., 2)
(., 1)
(., 1)
Z, Y, Zs
(R3)
Xe
X, Xs
(R1)
mode(i, i, o) append(X,Y,Z)R1,R2,R3 - ( (1)
X gt , remove R1, (2) Z Y (3) X gt
XeXs, (4) append(Xs,Y,Zs)R1,R2,R3, (5) Z lt
XeZs )
(R2)
deadR R1, bornR
19
Prototype implementation

• MMC 0.12.0
• Generate annotated, human-readable code
• Analysis time is acceptable
• 10 ms to 1.6 s, (agro_cnters, 480 LOC)
• nrev and qsort
• no more memory than the memory size of the input
  list.
• In general, lifetime of regions is shortest

20
To be done

• Proof of correctness
• Region points-to analysis
• produce correct memory model.
• Region liveness analysis
• extended version of the standard live variable
  analysis.
• Transformation soundness of the transformed
  program,
• a region is created before used (written to)
• a region is removed only when the program does
  not access (read from) it.

21
To realize Mercury with RBMM

• Enhance runtime system
• Region management system
• Region operations
• Mechanism to undo changes to memory work of
  Henning Kostis for Prolog
• Same idea applied to Mercury
• Maybe simpler no cut, no trail
• current algorithm works for a restricted set of
  deterministic Mercury programs no change

22
Future work

• Modular region analysis
• Module system is critical for software
  engineering
• A challenge
• Region analysis is global
• Research is little on this problem, only one work
  exists
• Idea make the analysis local, allow callers to
  control callees behaviour.
• More precise region analysis
• Combine RBMM with compile-time garbage collection
• Both are static approaches
• Combined benefits.