
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

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 .
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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 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 . 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi,
I believe it's mentioned here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSe...
Regards,
Shao Cheng
On Fri, Jan 18, 2019, 12:34 PM chessai .
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
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 .
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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Cheng,
That's perfect. Thanks
On Thu, Jan 17, 2019, 11:51 PM Shao, Cheng Hi, I believe it's mentioned here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSe... Regards,
Shao Cheng On Fri, Jan 18, 2019, 12:34 PM chessai . 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 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 . 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (3)
-
chessai .
-
Ryan Yates
-
Shao, Cheng