<div dir="ltr">Is the status quo still the same as it was in this paper?<div> <a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf" target="_blank">http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf</a><br>
</div><div><br></div><div>That is, there is a low-probability that a race will result in immutable objects being duplicated, but not mutable objects. But that leaves me wondering exactly which types are currently included in the duplicatable vs. "take the lock" category [2].</div>
<div><br></div><div>The reason I'm asking is because <i>defeating GHC compile-time and runtime optimizations</i> is precisely the goal of the recent work to make a safe/reliable infrastructure for CAS-based lockfree data structures in GHC. For example, the atomic-primops package uses the <font face="courier new, monospace">Any</font> kind and type coercions to store objects (pointers) in a form that makes them opaque to the compiler, preventing them from being unboxed and reboxed (changing pointer identity). </div>
<div><br></div><div>Actually, the current policy of this library that false negatives (failing CAS) must be tolerated, which is <b>usually</b> not an onerous obligation. So if the heap objects in question CAN be duplicated, that is still ok, but I would like to know if it is the case, that is, if <font face="courier new, monospace">Any</font> is treated any differently than, say, Int.</div>
<div><br></div><div>My guess is <b>no, </b>but I'd like to confirm this. That is, it seems that <font face="courier new, monospace">Any</font> effects the compiler (which <a href="http://www.haskell.org/ghc/docs/7.6.3/html/libraries/ghc-prim-0.3.0.0/GHC-Prim.html#g:25">promises not to enter the pointer</a>), but the physical representation of a thunk or function doesn't change, and thus the GC must treat those objects exactly as it would if they were <i>not</i> coerced to <font face="courier new, monospace">Any</font>. Sound right?</div>
<div><br></div><div>Cheers,</div><div> -Ryan</div><div><br></div><div>[1] P.S. The places I checked before asking on this list were here:</div><div> <a href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC</a></div>
<div><br></div><div>And here: <a href="http://ghc.haskell.org/trac/ghc/wiki/GarbageCollectorNotes" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/GarbageCollectorNotes</a></div><div><br></div><div>If there is newer documentation for the GC, please let me know.</div>
<div><br></div><div>[2] One hint is on line <a href="https://github.com/ghc/ghc/blob/d61c623ed6b2d352474a7497a65015dbf6a72e12/rts/StgMiscClosures.cmm#L531" target="_blank">531 of StgMiscClosures.cmm</a>:</div><div><br></div>
<div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre-wrap;background-color:rgb(255,255,204)">// PRIM rather than CONSTR, because PRIM objects cannot be duplicated by the GC.</span><br>
</div><div><br></div><div>Yet there are 62 different types of objects in ClosureTypes.hs, so I'm not sure what all the rules are.</div></div><div><br></div><div><br></div></div>