<div dir="ltr">Ok, that explains it.  Thanks!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15/09/2014 17:50, Ryan Yates wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm starting to get to the bottom of something that has been puzzling me<br>
for a while.  Recently commit 6d784c43592290ec16db8b7f0f2a01<u></u>2dff3ed497<br>
[1] introduced the GC write barrier for TVars.  Not fully understanding<br>
things and reading the commit message to be saying that this was an<br>
optimization, I implemented my hardware transactional memory support<br>
without the write barrier (avoiding the extra work inside a<br>
transaction).  This resulted in occasional crashes where a TVar which<br>
was point to a valid heap object when it was committed, pointed to<br>
garbage later.  My understanding was that the TVar ended up in a later<br>
generation then the value that it came to point to and without getting<br>
added to the mut list, the value was collected.  Adding the write<br>
barrier to all TVars written in my hardware transaction made the problem<br>
go away.<br>
<br>
While this all makes sense to me, what doesn't make as much sense is how<br>
STM prior to the commit above was not susceptible to the same problem.<br>
  Is there some machinery to avoid this issue that I'm still missing?<br>
</blockquote>
<br></div></div>
Sorry for the delay, I'm just catching up with this mailing list.<br>
<br>
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.<br>
<br>
Cheers,<br>
Simon<br>
</blockquote></div><br></div>