Re: [Haskell-cafe] IORef memory leak

Correct, here's a video of Simon explaining the thunk blackholing issue and its solution in GHC 7: http://vimeo.com/15573590 On 15 October 2010 21:31, Gregory Collins wrote:

Evan Laforge writes:

...

The only workaround I could find is to immediately read the value back out and 'seq' on it, but it's ugly.

Yep! C'est la vie unfortunately.

The way atomicModifyIORef works is that the new value isn't actually evaluated at all; GHC just swaps the old value with a thunk which will do the modification when the value is demanded.

It's done like that so that the atomic modification can be done with a compare-and-swap CPU instruction; a fully-fledged lock would have to be taken otherwise, because your function could do an unbounded amount of work. While that's happening, other mutator threads could be writing into your memory cell, having read the same old value you did, and then *splat*, the souffle is ruined.

Once you're taking a lock, you've got yourself an MVar. This is why IORefs are generally (always?) faster than MVars under contention; the lighter-weight lock mechanism means mutator threads don't block, if the CAS fails atomicModifyIORef just tries again in a busy loop. (I think!)

Of course, the mutator threads themselves then tend to bump into each other or do redundant work when it's time to evaluate the thunks (GHC tries to avoid this using "thunk blackholing"). Contention issues here have gotten radically better in recent versions of GHC I think.

Forgive me if I've gotten anything wrong here, I think Simon Marlow might be the only person who *really* understands how all this stuff works. :)

...

So two questions:

writeIORef doesn't have this problem.  If I am just writing a simple value, is writeIORef atomic?  In other words, can I replace 'atomicModifyIORef r (const (x, ())' with 'writeIORef r x'?

Any reason to not do solution 1 above?

Well if you're not inspecting or using the old value then it's safe to just blow it away, yes.

Cheers,

G -- Gregory Collins _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Push the envelope. Watch it bend.