[Gc] infinite loop since 6.3alpha5
lupus at ximian.com
Tue Jul 13 05:57:50 PDT 2004
On 07/09/04 Boehm, Hans wrote:
> Re: Incremental/generational
> 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.)
Yes, we'll introduce GC safe points that ensure the setting of a poinetr
and the write barrier cannot be interrupted.
> It probably
> makes sense for you to wait until 7.0alpha1 with this, especially since I
> doubt you're out of other things to work on.
> 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.
We'd prefer portable solutions, though of course it's nice to take
advantage of a particular systems's enhancements.
> 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.
Having the data at GC safe points would be enough and yes, this is
tricky, but we need to do it sooner or later. Testing it with libgc will
be helpful, since it also allows us to enable/disable the feature at
runtime until the issues are fixed.
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Gc