Re: [Haskell-cafe] pointer equality

David Barbour wrote:

On Wed, Jul 20, 2011 at 10:40 AM, Chris Smith 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