STM and GC write barrier

[Ryan Yates]

Ok, that explains it.  Thanks!

On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow <marlowsd at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/9cb61e17/attachment.html>