Garbage collector - Revision history

Cadrian: /* Native GC */

2014-01-05T19:21:24Z

Native GC

← Older revision		Revision as of 21:21, 5 January 2014
Line 8:		Line 8:

	[[Papers#Compiler_Support_to_Customize_the_Mark_and_Sweep_Algorithm.\|See this paper]] for details.		[[Papers#Compiler_Support_to_Customize_the_Mark_and_Sweep_Algorithm.\|See this paper]] for details.
		+
		+	From the source code:
		+
		+	The `mark_stack_and_registers' C function is called by the Garbage
		+	Collector (GC) of SmartEiffel. It has to be customized for some systems,
		+	but also for some C compilers. This file provides some definitions in the
		+	end and has to be completed for systems which need specific work.
		+
		+	On some architectures, addresses increase as the stack grows; or,
		+	conversely, addresses decrease as the stack grows. A C compiler may be
		+	clever enough to hide some root object inside registers. Unfortunately all
		+	registers are not always accessible via the C `setjmp' function!
		+
		+	Thus, in order to be able to use the GC on your architecture/C-compiler,
		+	you have to provide the correct `mark_stack_and_registers' function.
		+
		+	What is the `mark_stack_and_registers' function supposed to do? The
		+	`mark_stack_and_registers' function is supposed to notify the GC with all
		+	the possible roots one can find in the C stack and registers by calling the
		+	`gc_mark' function. A root is an object which must not be collected. The
		+	SmartEiffel GC already knows about some root objects like once function
		+	results or manifest strings. The `mark_stack_and_registers' function has to
		+	notify the other possible roots. Obviously, one can find in the C stack any
		+	kind of adresses, but the `gc_mark' function is clever enough to determine
		+	if the passed pointer is an Eiffel object or not. When the passed pointer
		+	reaches some Eiffel object, this object as well as its descendant(s) are
		+	automatically marked as un-collectable.
		+
		+	In order to provide the most appropriate `mark_stack_and_registers'
		+	function, the very first question is to know about the way the C stack is
		+	managed (addresses of the stack may increase or decrease as the C stack
		+	grows). The DEFAULT BEHAVIOUR FOR UNKNOWN SYSTEMS is to consider ADDRESSES
		+	DECREASE AS THE STACK GROWS, as it's the most common case. The global C
		+	variable `stack_bottom' is set with some pointer which is supposed to be
		+	the bottom of the stack (this variable is automatically initialized in the
		+	C main function). Note: using the current stack pointer inside
		+	`mark_stack_and_registers', it is quite obvious to determine if addresses
		+	increase or not as the C stack grows. Note2: on some systems, the stack is
		+	not in contiguous addresses. In such case, `mark_stack_and_registers' has
		+	to go through all the stack fragments.
		+
		+	Some roots may be stored only in registers and not in the C stack. In
		+	order to reach the registers as well, the first attempt is to use setjmp,
		+	in the hope that setjmp will save registers in the stack! Note: this
		+	technique do not work on processors using windows registers (such as sparc
		+	processors).

	== BDW GC ==		== BDW GC ==

Cadrian: /* BDW GC */

2014-01-05T18:36:00Z

BDW GC

← Older revision		Revision as of 20:36, 5 January 2014
Line 17:		Line 17:
	The missing parts are:		The missing parts are:
	* a lot of testing (esp. dynamic arrays, weak references, agents)		* a lot of testing (esp. dynamic arrays, weak references, agents)
−	* total GC cycle at the end of the program (Eiffel requires that all the objects are disposed at exit, and some programs or libraries rely on that behaviour)	+	* total GC cycle at the end of the program (Eiffel requires that all the objects are disposed at exit, and some programs or libraries rely on that behaviour, usually for checks — is it important?)
	* Liberty does not make use of the parallel or incremental collectors		* Liberty does not make use of the parallel or incremental collectors

Cadrian: /* Native GC */

2014-01-04T21:48:31Z

Native GC

← Older revision		Revision as of 23:48, 4 January 2014
Line 7:		Line 7:
	The native GC is generated at the same time as the rest of the code, allowing efficient use of the memory by splitting it in chunks of known size.		The native GC is generated at the same time as the rest of the code, allowing efficient use of the memory by splitting it in chunks of known size.

−	~~See~~ [~~http://www~~.~~liberty-eiffel.org/papers/ismm98.pdf~~ this paper] for details.	+	[[Papers#Compiler_Support_to_Customize_the_Mark_and_Sweep_Algorithm.\|See this paper]] for details.

	== BDW GC ==		== BDW GC ==

Cadrian: Created page with "Liberty Eiffel provides two garbage collector implementations. Most core libraries are also well equipped to minimize memory requirements in the case that ''no'' GC is used. ..."

2014-01-04T21:43:20Z

Created page with "Liberty Eiffel provides two garbage collector implementations. Most core libraries are also well equipped to minimize memory requirements in the case that ''no'' GC is used. ..."

New page

Liberty Eiffel provides two garbage collector implementations.

Most core libraries are also well equipped to minimize memory requirements in the case that ''no'' GC is used.

== Native GC ==

The native GC is generated at the same time as the rest of the code, allowing efficient use of the memory by splitting it in chunks of known size.

See [http://www.liberty-eiffel.org/papers/ismm98.pdf this paper] for details.

== BDW GC ==

The Boehm-Demers-Weiser conservative collector is also supported. The minimal required version is currently 7.2.

See [https://github.com/ivmai/bdwgc/ the github repository]

The missing parts are:
* a lot of testing (esp. dynamic arrays, weak references, agents)
* total GC cycle at the end of the program (Eiffel requires that all the objects are disposed at exit, and some programs or libraries rely on that behaviour)
* Liberty does not make use of the parallel or incremental collectors