Sorry for the delay, I'm just catching up with this mailing list.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?
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