[Haskell-cafe] rts nursery and stopping the world minor gc

Brandon Allbery allbery.b at gmail.com
Thu Jun 8 19:45:19 UTC 2017


On Thu, Jun 8, 2017 at 3:29 PM, Ruben Astudillo <ruben.astud at gmail.com>
wrote:

> On 08/06/17 15:08, Brandon Allbery wrote:
> > It's not just allocation: if it didn't get garbage collected, then
> > there is *at least* one reference to it that needs to be updated.
>
> which reference is that?. Immutability means that old data can't
> reference the new one, right?. What kind of reference (apart from live
> data on the stack) can we have on new data on the nursery?
>

Another reference within the same nursery. Now consider that the same
nursery can *also* contain newly created threads, which can be scheduled
just like existing ones.

Between two garbage collections, we may have:

- allocation of new values
- spawning of new sparks which have access to said values

If you now have multiple hardware threads, these can be running
concurrently and allocating their own heap values which reference those
shared values: for example, each is building its own list of cons cells
referencing the value in different ways as specified by other values passed
to the thread. Relocating the shared value from the nursery now requires
updating all such thread-specific cons cells. Those heap values are also
being promoted out of the nursery, but that doesn't change anything;
copying them does not magically also update the copied things being pointed
to, that is part of what GC does.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170608/296199b2/attachment.html>


More information about the Haskell-Cafe mailing list