
Simon Marlow wrote a paper about this issue a few years ago. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/local-gc... The conclusion IIRC was that while maintaining thread-local heaps could reduce the amount of time spent in GC, the benefit was surprisingly small, and came at a sizable cost in code complexity. So GHC HQ decided it was not worth merging at the time. I don't know if there's been any work on that front since the paper though. On Thu, Jun 8, 2017, at 12:45, Brandon Allbery wrote:
On Thu, Jun 8, 2017 at 3:29 PM, Ruben Astudillo
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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.