MutVar# and GC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

MutVar# and GC

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: MutVar# and GC

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: MutVar# and GC

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: MutVar# and GC

Shao, Cheng
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 . <[hidden email]> 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 <[hidden email] 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 . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: MutVar# and GC

chessai .
Cheng,

That's perfect. Thanks

On Thu, Jan 17, 2019, 11:51 PM Shao, Cheng <[hidden email] wrote:
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 . <[hidden email]> 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 <[hidden email] 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 . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs