Difference between revisions of "Interfacing the Garbage Collector"
m (→Introduction) |
m (→The root set) |
||
| Line 15: | Line 15: | ||
===The root set=== | ===The root set=== | ||
| + | The root set of EiffelStudio is surprisingly complex. Only the more interesting part is shown here. | ||
| + | |||
| + | ====The loc_set==== | ||
| + | foo (s: STRING; i: INTEGER): LIST [ANY] | ||
| + | local | ||
| + | l_b: BOOLEAN | ||
| + | l_a: ANY | ||
| + | do | ||
| + | l_a := "df" | ||
| + | create {LINKED_LIST [ANY]}Result.make | ||
| + | print (s) | ||
| + | end | ||
Revision as of 00:31, 17 January 2007
Warning: Warning: Article under development
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. The exact mechanisms behind the GC are not of concern here.
Introduction
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.
Thats about all there is to know for interfacing the GC, for modifying or even extending him a little more in-deft might be handy but is not provided here.
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 of EiffelStudio is surprisingly complex. Only the more interesting part is shown here.
The loc_set
foo (s: STRING; i: INTEGER): LIST [ANY]
local
l_b: BOOLEAN
l_a: ANY
do
l_a := "df"
create {LINKED_LIST [ANY]}Result.make
print (s)
end
