Interfacing the Garbage Collector - Revision history

Manus at 21:25, 28 January 2008

2008-01-28T21:25:47Z

2007-04-11T10:09:06Z

2007-01-19T18:14:27Z

Use new wiki syntax highlighting tags

2007-01-18T12:39:50Z

‎Introduction

2007-01-18T12:39:35Z

‎The root set

2007-01-18T12:38:15Z

‎Introduction

2007-01-18T12:37:56Z

2007-01-18T12:36:49Z

‎Introduction

2007-01-18T10:28:02Z

fixed typo

2007-01-18T10:27:09Z

small grammar fix

@@ Line 1: / Line 1: @@
 [[Category:Compiler]]
-{{Warning|'''Warning''': Article under development}}
+{{UnderConstruction}}
 This article tries to explain, how the EiffelStudio GC works together with the runtime. It should help the programmer to better understand the C and byte code generated by EiffelStudio.

@@ Line 28: / Line 28: @@
 |-valign="top" -halign="center"
+|
-<code>[eiffel,N]foo (s: STRING; i: INTEGER): LIST [ANY]
+<eiffel>
     local
        b: BOOLEAN
@@ Line 35: / Line 36: @@
        ...
     end
-</code>
+</eiffel>
+|
 |}
@@ Line 46: / Line 47: @@
 |-valign="top" -halign="center"
+|
-<code>[c,N]/* foo */
+<c>
 EIF_REFERENCE Fadkw7f (EIF_REFERENCE Current,
                         EIF_REFERENCE arg1,
@@ Line 65: / Line 67: @@
     return Result;
+}
-</code>
+</c>
+|
 |}

@@ Line 5: / Line 5: @@
 The exact mechanisms behind the GC are not of concern here.
-==Introduction==
+====Introduction====
 Most important thing first, EiffelStudio has a mark and sweep moving Garbage Collector (GC) (instead of moving GC one may say compacting GC).

@@ Line 16: / Line 16: @@
 To recap, the GC needs to know the current root set and enough information to traverse the objects currently on the heap. The runtime and the generated code on the other side need to be able to cope with objects that change their memory location after a GC run.
-===The root set===
+====The root set====
-The root set of EiffelStudio is surprisingly complex. Only the more interesting part is shown here.
+The root set of EiffelStudio is surprisingly complex. Only the more interesting part is shown here. It is consisting of several stacks that will be presented here.
 ====The loc_set====

@@ Line 8: / Line 8: @@
 Most important thing first, EiffelStudio has a mark and sweep moving Garbage Collector (GC) (instead of moving GC one may say compacting GC).
-A mark and sweep GC traverses during the mark phase all the objects, that are reachable from a given root set (locals, arguments uws...). After that, the not reached objects are detected as garbage and may be freed. To avoid memory fragmentation the GC may move around the reached objects.
+A mark and sweep GC traverses during the mark phase all the objects, that are reachable from a given root set (locals, arguments etc...). After that, the not reached objects are detected as garbage and may be freed. To avoid memory fragmentation the GC may move around the reached objects.
 The ES GC actually moves objects during the marking phase and thus doesn't need a special sweep traversal.

← Older revision		Revision as of 12:36, 18 January 2007
Line 9:		Line 9:

	A mark and sweep GC traverses during the mark phase all the objects, that are reachable from a given root set (locals, arguments uws...). After that, the not reached objects are detected as garbage and may be freed. To avoid memory fragmentation the GC may move around the reached objects.		A mark and sweep GC traverses during the mark phase all the objects, that are reachable from a given root set (locals, arguments uws...). After that, the not reached objects are detected as garbage and may be freed. To avoid memory fragmentation the GC may move around the reached objects.
		+
		+	The ES GC actually moves objects during the marking phase and thus doesn't need a special sweep traversal.

	Thats about all there is to know for interfacing the GC, for modifying or even extending it a little more in-deft might be handy but is not provided here.		Thats about all there is to know for interfacing the GC, for modifying or even extending it a little more in-deft might be handy but is not provided here.

@@ Line 75: / Line 75: @@
 *RT_GC_PROTECT
 *RT_GC_WEAN
-RT_GC_PROTECT pushes the pointer of a reference onto the stack and RT_GC_WEN pops the top entry from the stack.
+RT_GC_PROTECT pushes the pointer of a reference onto the stack and RT_GC_WEAN pops the top entry from the stack.
 This stack is managed by the runtime itself and not by generated code (as opposed to the loc_set).

@@ Line 67: / Line 67: @@
 |}
-Note, that the macro RTLR pushes the address of its parameter on loc_set and not the parameter itself. This makes it possible for the GC to rewrite the protected references when he moves the objects.
+Note, that the macro RTLR pushes the address of its parameter on loc_set and not the parameter itself. This makes it possible for the GC to rewrite the protected references when it moves the objects.
 ====The loc_stack====