STM and GC write barrier

Ryan Yates fryguybob at gmail.com
Mon Sep 15 16:50:06 UTC 2014


Hi All,

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?

Ryan


[1]:
https://github.com/ghc/ghc/commit/6d784c43592290ec16db8b7f0f2a012dff3ed497
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140915/1517d72e/attachment.html>


More information about the ghc-devs mailing list