Revision as of 23:46, 9 April 2007

Overview

In this article, I introduce a way in Eiffel to help fixing memory leaks. I call it Back to Once approach.

Introduction

What is Back to Once? The general idea is that we take a memory short in which one provide a start object, in principle part of leaking objects, to Memory Analyzer that returns routes from the given object to once objects. With these routes one can find out bad links and corresponding code more easily. This approach is based on the point that one or more bad links MUST exist in found routes as long as the given start object is part of leaks.

Explanation in Example

Example system code

We use the following code to construct an example system where A-L are classes with simple attributes and set_X routines.

make_relation is
		local
			a: A
			b: B
			c: C
			e: E
			f: F
			g: G
			h: H
			i: I
			j: J
			l: L
		do
			create a
			create b
			create c
			create e
			create f
			create g
			create h
			create i
			create j
			create l
 
			a.set_e (e)
			a.set_j (j)
			b.set_a (a)
			c.set_b (b)
			e.set_f (f)
			e.set_l (l)
			f.set_g (g)
			f.set_i (i)
			g.set_h (h)
			h.set_a (a)
			i.set_l (l)
			j.set_k (k)
			l.set_c (c)
			array_list.extend (h)
		end
 
	array_list: ARRAYED_LIST [H] is
		once
			create Result.make (2)
		end
 
	k: K is
		once
			create Result
		end

Object relations in example system

With previous code, the object relations in the memory should like this:

Once is an object of ARRAYED_LIST [H], K is an once object and one may have guessed, M is a object of SPECIAL [M].

Fixing memory leaks in sample system

The first step is to choose an object as a start object

As I said, a start object should be an object of the leaks. Otherwise, routes found are valid routes and useless for the leak fixing. How to identify an object part of leaks? Programmers can come up with various approaches. Digging memory leaks of EiffelStudio mentions one of them.

Now we suppose B is of leaks.

Finding routes of Back to Once for B

With Memory Analyzer, we get the route: Route1: ARRAYED_LIST [H] -> SPECIAL [H] -> H -> A -> E -> F -> I -> L -> C -> B

Of course, one may get different one, but it helps us fix leaks in the same way.

The route is demonstrated in the following diagram with blue arrows.

Decision on bad links to cut

Now we have a Back to Once route in hand, how does it help?

We know that there is at least a bad link in this route, how to decide a black sheep, maybe more? It depends. Take a look at the following diagram, there are four regions R1-R4. One need to decide objects in this route a leak or not, in other words, one need to find the edge of leaks and non-leaks. Obviously, in this example, not all object in R3 are possibly leaks, because we know that area: SPECIAL [X] is one attribute of ARRAYED_LIST. We can do little to cut this link out of the base library. The rest R1, R2 and R3 are all possible invalid regions, namely leaks. Respectively links M->H, H->A and A-E are possible edges need to cut. The decision of edge is made by the programmer who knows the logic in his system. If A is part of valid object and E is not, the programmer knows that A->E should be cut programmatically in his system. Then G, F, E, B, I, L and C will be garbage collected. Programmers can have more regions and decide which link is of the edge.

Fixing leaks in all routes

Once a leak is fixed, one should relaunch Memory Analyzer to find the next route and fix it in the same way until all leaks by one operation are fixed.