On Thu, Jun 8, 2017 at 3:45 PM, Brandon Allbery
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.
I should also point out that the fact that the cons cells for the other thread are in a different nursery from the shared value *also* does not change anything (aside from possibly complicating the implementation of the garbage collector). They still must be updated to point to the new value, so that thread must be quiescent/not actively accessing through the pointer being updated. This stuff *is* complicated; I've had to stop and think through the whole thing a few times myself. And I might still have some things wrong. :/ -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net