Ok, that explains it. Thanks! On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow <[email protected]> wrote:
> On 15/09/2014 17:50, Ryan Yates wrote: > >> I'm starting to get to the bottom of something that has been puzzling me >> for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 >> [1] introduced the GC write barrier for TVars. Not fully understanding >> things and reading the commit message to be saying that this was an >> optimization, I implemented my hardware transactional memory support >> without the write barrier (avoiding the extra work inside a >> transaction). This resulted in occasional crashes where a TVar which >> was point to a valid heap object when it was committed, pointed to >> garbage later. My understanding was that the TVar ended up in a later >> generation then the value that it came to point to and without getting >> added to the mut list, the value was collected. Adding the write >> barrier to all TVars written in my hardware transaction made the problem >> go away. >> >> While this all makes sense to me, what doesn't make as much sense is how >> STM prior to the commit above was not susceptible to the same problem. >> Is there some machinery to avoid this issue that I'm still missing? >> > > Sorry for the delay, I'm just catching up with this mailing list. > > Prior to this commit, the garbage collector would treat *all* TVars in the > old generation as potentially modified, and traverse them all during every > GC. This is expensive when there are a lot of TVars, which meant that > TVar-based data structures such as TChan would perform very badly with a > large number of elements. The fix is to track writes to TVars in the old > generation, which is what that commit did. > > Cheers, > Simon >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
