[Gc] Performance improvements

Juan Jose Garcia Ripoll lisp at arrakis.es
Mon Jul 11 04:42:56 PDT 2005


Hi,

I have a couple of questions regarding my current use of the garbage
collector in ECL (http://ecls.sf.net), a Common-Lisp interpreter and
compiler.

The fact is that, both for performance and for compatibility with an
older garbage collector, ECL must know all possible roots that point to
lisp data, with the exception of the stack and registers, which are
expected to be scanned conservatively.

With this in mind, up to now I have taken these steps:

+ set GC_no_dls=1
+ create a custom function for GC_push_other_roots which marks all
static data in ECL

The problems I have found are

1) GC_no_dls has no effect in the Mac OSX port. I had to change the file
gc/dyn_load.c in the following way so as to prevent registering the
static data from dynamically linked libraries.

static void GC_dyld_image_add(struct mach_header* hdr, unsigned long
slide) {
    unsigned long start,end,i;
    const struct section *sec;
    if (GC_no_dls) /* My change! */
	return;

2) I have regions of memory which I use for stacks in the interpreter.
Typically only a percentage of this regions contains pointers, while the
rest should be discarded. Until now I was using something like 

 GC_push_conditional((ptr_t)env->stack, (ptr_t)env->stack_top, 1);
 GC_set_mark_bit((ptr_t)env->stack);

However, in experiments with the latest garbage collector (v.6.5) I
found that even the region above env->stack_top is scanned for pointers.
I have changed the interpreter so that env->stack is allocated with
GC_malloc_atomic() but I am unsure about this change.

3) It would be useful to have either a runtime or configuration flag to
make the Boehm-Weiser garbage collector less conservative: i.e. impose
that the user should supply all roots, except for the stacks, which
would be scanned conservatively. I could code this myself, but I am not
very comfortable with the inner guts of the collector. Also, I think
this is a useful extension from which other interpreters or compiled
environments could profit.

I would really appreciate answers to these questions and also other tips
on how to best use the garbage collector in a project of the type of
ECL.

Regards,

Juanjo



More information about the Gc mailing list