[bitc-dev] GC collect without stop the world

[Jonathan S. Shapiro]

On Thu, Feb 3, 2011 at 9:35 PM, Ben Kloosterman <bklooste at gmail.com> wrote:

> It was mentioned earlier that the standard library may not use copies that
> may be non atomic due to the GC.. I should have asked this at the time but
> is there a point ? Can you make a GC compaction  or move and not stop the
> world without a scheme that is incredibly costly ?  For a start you must
> stop the threads to scan the stack...
>

The problem isn't limited to libraries. The best work on this, as I've
mentioned in the past, is the work be Steensgaard, though his work does not
consider unboxed unions.

The limit on incrementalism is that a given object has either been copied or
it has not. In a lock-free concurrent collector, the approach is to contrive
to notice when the object has changed and abandon (or retry) the copy when
this occurs. Provided the upper bound on object size is small enough, this
eventually converges, though the argument about it is tricky.

I personally don't really believe in this approach. I think a better model
is to imagine that there *is* a lock between the mutator and the GC, but
that we want to establish a bound on the duration of this lock by limiting
the number of words that the lock covers. We can then view the lock-free
implementation as an optimistic optimization.

Not only is it *not* incredibly costly; it works quite nicely.

But also: the metric of "costly" needs to be examined. In a time when
additional cores are idle and unusable, bounding in-band wait and
establishing a floor (i.e. a guarantee) on GC progress may be much more
important than maximizing GC performance.

Which is why GC tuning remains a black art...

shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20110207/46561937/attachment.html