[Gc] infinite loop since 6.3alpha5
hans.boehm at hp.com
Fri Jul 9 14:44:17 PDT 2004
The beginnings of software write-barrier support are in
my 7.0alpha1 tree. The plan is to have it
replace "stubborn" allocation, which was intended to solve a similar
problem. It's a little tricky to set this up so that you avoid
races. I think it requires some care in the collector beyond just the
dirty bit implementation. (The issue is with stopping a thread between
the time the dirty bit gets set and the pointer is updated.)
makes sense for you to wait until 7.0alpha1 with this, especially since I
doubt you're out of other things to work on.
The 7.0 solution would still use hblk granularity. But those would no longer
be tied to hardware page size, and should probably be smaller.
We're also experimenting with a kernel-based dirty bit implementation
on Itanium, which solves many of the current problems. But I'm not sure what
the odds are of getting that into especially non-IA64 kernels.
Re: stack scanning
Precise stack scanning is likely to be tricky. I suspect much of the benefit
would come from identifying dead locations on the stack and not scanning those.
My impression is that generally has more impact than actual misidentifications.
(Static data is different, since there tends to be more of it, and it more
commonly holds "random", e.g. compressed, data.) So you would have to be careful
to also capture liveness fairly accurately, possibly at instruction resolution.
> -----Original Message-----
> From: Paolo Molaro [mailto:lupus at ximian.com]
> Sent: Friday, July 09, 2004 10:52 AM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] infinite loop since 6.3alpha5
> 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