STM and GC write barrier

[Simon Marlow]

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