[Gc] infinite loop since 6.3alpha5

Paolo Molaro lupus at ximian.com
Fri Jul 9 10:52:01 PDT 2004

On 06/15/04 Boehm, Hans wrote:
> Unfortunately, this looks like normal behavior to me.  There are a number of
> things you can do which have roughly the same effect of reducing the final
> heap size to around 200MB:
> 1) Use GC_malloc_atomic_ignore_off_page, which tells the collector that
> pointers to the interior of this block can be ignored.
> 2) Use a 64-bit machine.
> 3) (Didn't try this.) Turn off interior pointer recognition in general.

Thanks for the feedback.
We're starting to use libgc more and more in a way to reduce the
conservative approach in an effort to improve performance and prepare
for enabling the use of a precise and moving GC later on.
We already use the typed allocation support and we just wrote the
support code to avoid adding to the static roots the .bss and .data
The same trick helped with my test program, too: at the end of the run
the amount of memory reported in top was about 112 MB, which is quite
good (I was getting 400+ MB before). Just adding 
	GC_no_dls = 1;
at the start of main makes for a big difference:-)

We are also considering a few other changes, too. One is enabling the
generational/incremental capabilities by using write barriers instead 
of the current signal-based approach which can cause some
incompatibilities. We'd mark pages or finer-grained blocks as dirty
on stores. Do you think this would work? The changes required in
libgc should be minimal and they may be of interest to other people,
too, if the use libgc in a setting where they have tight control of what
happens to heap objects. Any advice would be welcome.
The other change is related to stack scanning: avoid the scan
of much of the root set gave good results both for speed and memory
retention. I guess a less conservative approach at stack scanning would
give some improvement, too. The idea is to scan conservatively
only the 'C' stack and scan precisely the managed stack (the stack
allocated by our jit-generated code), using a callback mechanism.
Any advice you may have on this is welcome, too.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Gc mailing list