[Haskell-cafe] pointer equality

[Bertram Felgenhauer]

David Barbour wrote:
> On Wed, Jul 20, 2011 at 10:40 AM, Chris Smith <cdsmith at gmail.com> wrote:
> > The point, I think, is that if pointer equality testing really does what
> > it says, then there shouldn't *be* any correct implementation in which
> > false positives are possible.  It seems the claim is that the garbage
> > collector might be moving things around, have just by chance happened to
> > place the second value in the spot formerly occupied by the first, and
> > have not updated the first pointer yet.  But if that's the case, and
> > it's executing arbitrary user code that may refer to that memory, then
> > the garbage collector contains race conditions!
> 
> You assume that the GC uses the same primitive as the developer, and is
> inherently subject to its own race conditions.
> 
> But Bertram has said that false positives are not possible. I can only
> assume that the pointer comparison is atomic with respect to the GC.

That's right. A lot of things that the CMM code (and eventually the
machine code) generated by ghc does is atomic with respect to GCs - from
a single worker thread's point of view, GCs only happen when it tries to
allocate some memory. (Then it does a heap check, and if that fails,
saves some state and hands control over to the garbage collector. If the
state contains pointers, the GC will know that and adjust them. Finally
the state is restored and execution resumes.)

Between these points, the code is free to access pointers on the stack
and heap and dereference them, without having to worry about GC changing
the memory under its nose.

The reallyUnsafePointerEquality# primitive is implemented at this low
level, and there are no intervening heap checks, and thus no GCs that
could interfere with the comparison.

Best regards,

Bertram