MutVar# and GC
cheng.shao at tweag.io
Fri Jan 18 04:51:19 UTC 2019
I believe it's mentioned here:
On Fri, Jan 18, 2019, 12:34 PM chessai . <chessai1996 at gmail.com> wrote:
> That makes perfect sense, thanks. Is that documented explicitly anywhere?
> If not, I'd like to add the documentation to any place relevant.
> On Thu, Jan 17, 2019, 8:19 PM Ryan Yates <fryguybob at gmail.com wrote:
>> 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.
>> On Thu, Jan 17, 2019 at 4:29 PM chessai . <chessai1996 at gmail.com> wrote:
>>> 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.
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs