Back to once approach - Revision history

Ted: /* Search Routes in Memory Analyzer */

2008-08-14T03:50:25Z

‎Search Routes in Memory Analyzer

Ted at 03:48, 14 August 2008

2008-08-14T03:48:54Z

Manus: Back to once appoarch moved to Back to once approach: Fixed typo

2007-05-30T19:19:20Z

Back to once appoarch moved to Back to once approach: Fixed typo

Ted: /* Decision on bad links to cut */

2007-04-10T08:46:51Z

‎Decision on bad links to cut

Ted: /* Decision on bad links to cut */

2007-04-10T06:37:37Z

‎Decision on bad links to cut

Ted at 06:07, 10 April 2007

2007-04-10T06:07:26Z

Ted: /* Explanation in Example */

2007-04-10T06:05:45Z

‎Explanation in Example

Ted at 04:58, 10 April 2007

2007-04-10T04:58:41Z

New page

[[Category:Memory leak]]
=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 {{red | one or more bad links MUST exist in found routes as long as the given start object is part of leaks}}.
=Explanation in Example=

@@ Line 95: / Line 95: @@
 * Switch to Object Grid panel. Expand object nodes and choose a starting object by the check box in the third column.
 * Enable statics collection in the tool bar.
-* Click Refresh information button in the tool bar again. (Be patient, this will take some minutes to finish depending, seriously. It varies depending on machines, how big the system is and how the system was compiled.)
+* Click Refresh information button in the tool bar again. (Be patient, this will take some minutes to finish dependingly, seriously. It varies depending on machines, how big the system is and how the system was compiled.)
 * Switch to Search Route panel. And now one can click Search Next Route button on the top. The results are listed leading by once objects found and trailing by the starting object.

← Older revision		Revision as of 03:48, 14 August 2008
Line 90:		Line 90:
	===Fixing leaks in all routes===		===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.		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.
		+
		+	=Search Routes in Memory Analyzer=
		+	* In any situation one expect, click Refresh information button in the tool bar.
		+	* Switch to Object Grid panel. Expand object nodes and choose a starting object by the check box in the third column.
		+	* Enable statics collection in the tool bar.
		+	* Click Refresh information button in the tool bar again. (Be patient, this will take some minutes to finish depending, seriously. It varies depending on machines, how big the system is and how the system was compiled.)
		+	* Switch to Search Route panel. And now one can click Search Next Route button on the top. The results are listed leading by once objects found and trailing by the starting object.

@@ Line 85: / Line 85: @@
 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.
 [[Image:Leak_example_system2.PNG]]
 ===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.

@@ Line 84: / Line 84: @@
 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.
+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.
 [[Image:Leak_example_system2.PNG]]
 ===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.

@@ Line 5: / Line 5: @@
 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 {{red | 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===
+==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.
 <code>[eiffel,N]
@@ Line 58: / Line 58: @@
 		end
 </code>
-===Object relations in example system===
+==Object relations in example system==
 With previous code, the object relations in the memory should like this:
@@ Line 65: / Line 65: @@
 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===
+==Fixing memory leaks in sample system==
-====The first step is to choose an object as a start object====
+===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.
 {{Red|Now we suppose B is of leaks.}}
-====Finding routes of Back to Once for B====
+===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
@@ Line 81: / Line 81: @@
 [[Image:Leak_example_system3.PNG]]
-====Decision on bad links to cut====
+===Decision on bad links to cut===
 Now we have a Back to Once route in hand, how does it help?
@@ Line 87: / Line 87: @@
 [[Image:Leak_example_system2.PNG]]
-====Fixing leaks in all routes====
+===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.

← Older revision	Revision as of 19:19, 30 May 2007
(No difference)

← Older revision		Revision as of 06:05, 10 April 2007
Line 5:		Line 5:
	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 {{red \| one or more bad links MUST exist in found routes as long as the given start object is part of leaks}}.		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 {{red \| one or more bad links MUST exist in found routes as long as the given start object is part of leaks}}.
	=Explanation in Example=		=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.
		+	<code>[eiffel,N]
		+	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
		+	</code>
		+	===Object relations in example system===
		+	With previous code, the object relations in the memory should like this:
		+
		+	[[Image:Leak_example_system1.PNG]]
		+
		+	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.
		+
		+	{{Red\|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.
		+
		+	[[Image:Leak_example_system3.PNG]]
		+
		+	====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.
		+	[[Image:Leak_example_system2.PNG]]
		+
		+	====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.