Hi, I believe it's mentioned here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSets Regards, Shao Cheng On Fri, Jan 18, 2019, 12:34 PM chessai . <[email protected]> wrote: > Ryan, > > That makes perfect sense, thanks. Is that documented explicitly anywhere? > If not, I'd like to add the documentation to any place relevant. > > Thanks > > On Thu, Jan 17, 2019, 8:19 PM Ryan Yates <[email protected] wrote: > >> Hi, >> >> Because GHC's GC is generational it needs a way to handle heap objects >> from older generations that point into younger generations. This only >> happens when an older object is mutated to point to a younger object. GHC >> solves this by invoking the GC write barrier (not to be confused with write >> barriers for memory synchronization) `dirty_MUT_VAR`. This will add that >> mutable object to a mutable list that will be traversed in minor GCs along >> with young generation roots. Additionally the write barrier will mark the >> heap object as "dirty" to avoid adding it to the list more than once. >> >> Ryan >> >> On Thu, Jan 17, 2019 at 4:29 PM chessai . <[email protected]> wrote: >> >>> Devs, >>> >>> I've heard from a few friends that MutVars, TVars, etc. are more >>> challenging for the garbage collector. I'm writing to ask if someone can >>> answer: 1. Is this true, and 2: Why? I can't seem to find anything like a >>> writeup or documentation that mentions this. The HeapObjects trac page also >>> mentions nothing about these supposed difficulties that GC faces with >>> mutable heap objects. >>> >>> Thanks >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
