Runtime: Epic: GC Regions Support

Created on 26 Oct 2020  路  15Comments  路  Source: dotnet/runtime

We are switching segments to regions for managing memory on the GC heap. Segments have their own benefits, eg, checking if an address is in ephemeral requires comparing with 2 values (in Workstation case) but regions enable many optimizations that we've been wanting to have for a while. For example -

  • Currently there鈥檚 no way to exchange memory between different generations without a compacting GC so if BGC builds up a lot of free space in gen2/LOH and gen2 has a lot more free spaces than LOH, there鈥檚 not a way to repurpose memory in gen2 for LOH. Another example is we often observe a lot of free spaces in gen0 due to pinning and we cannot repurpose it for other generations. With regions we can repurpose empty regions to any generation which will solve both problems. We could also choose to decommit these free spaces but that would require its own bookkeeping and we might as well just switch to regions.
  • This will also help with container perf - because we repurpose free spaces to other generations, we can regulate the memory usage much more easily without incurring full compacting GCs.
  • One of the evolutions I鈥檇 like to make in GC is to decouple the GC threads and their respective heaps and this will allow that to happen a lot more naturally.
  • This will build a solid foundation for new flavors of GCs like incremental/concurrent compacting GCs.
Team Epic area-GC-coreclr

All 15 comments

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

@mangod9 been wondering about this for a while. Any info you might share?)

Hey @En3Tho, we are just getting started and will add more details as we make progress. If there are any specific details you are interested in please let us know. Thx!

@mangod9 Thank you for an answer. For now, I guess it would be really cool if you could at least briefly describe what this is about (a new under-the-hood mechanism to make GC even faster or a new kinda "give me a memory region, let me so my stuff and have it back", api, sorta like arraypool/malloc, but more general version.
For now we can only wonder.

it's my fault - I was supposed to write the description. I'll edit the 1st comment on the thread with the description.

Hoh last bullet sounds particularly interesting of course others sound nice too. The only thing sour is new flavors of gc are multiyears efforts on their own i suspect never mind switch to regions itself. Maybe im too pessimistic?

@Maoni0, do you think regions would make it easier to support custom alignments (such as 16 or 32-byte alignments) for objects/arrays?

Or would that still be relegated to the POH and extending the GC.AllocateArray method to support specifying alignments?

@tannergooding those are orthogonal features. the reason we haven't enabled alignment is just because we haven't had time due to other more urgent work. it's something I want to enable because it's clearly useful for some (very specific) scenarios. I know you care about it a lot 馃槂 it's in the queue... just haven't got there yet.

Will regions be helpful in supporting safe memory mapped files as byte arrays?

@mjsabby what kind of issues do you hit currently doing that? are you talking about ro segments or something else?

It鈥檚 not safe. It can be made safe if memory mapped files are backed by GC regions.

There was a discussion on GitHub with @GrabYourPitchforks and @jkotas

regions make no difference for that particular issue - I presume you are talking about #37227. I don't think GC is actually a big part in that issue - essentially from GC's POV, if it gets more ro segs it's not a big deal - we don't reclaim ro segs anyway (they can only be removed by the user code). all GC cares about is if an object points to something on the ro segs it needs to be a legit object. I saw that @jkotas already said the special treatment of Dispose was too expensive.

Today we look at the stack for by refs, couldn't we also look at another special location for memory mapped files? I thought GC regions could accomplish that in a more natural way, maybe not, and the discussion can then stay in that thread.

@mjsabby Let's keep this discussion in #37227. Regions do not help with this at all.

Regarding GC can a truly pauseless GC be introduced. E.g. Azul has C4: The Continuously Concurrent Compacting Collector

Was this page helpful?
0 / 5 - 0 ratings