Null (allocate-only) GC proposal

[wizzard0]

Proposal: create a No-op GC, selectable at application start (via app manifest, command line option, putting Local GC library next to the executable, etc).

Rationale is about the same as for the Epsilon GC:

• Performance testing, to be able to separate GC-induced performance variations
• Functional testing, e.g. to quickly detect allocation rate spikes in applications that are supposed to run with low allocation rate
• Example GC for developing/integrating other GC engines
• Squeezing the last bit of performance where the app is either short-lived (e.g. request handler) or already has low to none allocation rate, by removing memory barrier overheads and so on.

[davidfowl]

TryStartNoGCRegion might be good enough for this? https://msdn.microsoft.com/en-us/library/system.gc.trystartnogcregion(v=vs.110).aspx

/cc @Maoni0

[adamsitnik]

as soon as this is implemented I add the support to BenchmarkDotNet for it ;)

[jkotas]

This type of cutting edge GC improvements is exactly what we are hoping to enable with the local GC project.

[wizzard0]

@davidfowl TryStartNoGCRegion was a great start, but last time I checked it only gets you up to 256 MB of heap for small objects + 256 mb LOH max.

And memory barriers and associated overhead remain the same (I am aware that compacting GC may actually increase performance compared to no GC at all in some scenarios)

[Maoni0]

I believe having the API that allows you to specify a NoGC region is a much better choice for the majority of our customers than having a totally separate GC that does no GC because you have the flexibility to revert back to doing normal GCs when you need to.

You can certainly allocate more than that if you use Server GC for SOH. For LOH you can already allocate more than 256mb even with Workstation GC. If this is not what you are observing please provide a repro and I can take a look (I just verified and I can definitely allocate much more). You can also increase the segment size so you can allocate more for SOH even with Workstation GC but this config (GCSegmentSize) is currently only available on Desktop. We can add it on Core if needed. Also we can just not have the limit about the SOH wrt segment size. We don't have a theoretical limit today - it's just that so far we've always had the same segment size for SOH. We just need to do some testing to make sure that having different seg sizes doesn't cause problems (I don't think it would but I'd still like to do some testing to make sure).

Your point about the cost of overhead (which is in the write barrier) is valid and is also completely solvable for NoGC region - it's not even hard to do. Whether/when we want to implement this would completely depend on how much it's needed - it's very rare that I get complaints about the write barrier cost from folks. But if you have a valid scenario I'd like to hear it.

[wizzard0]

@Maoni0 Thanks for the detailed explanation! I will repeat my TryStartNoGCRegion/GCSegmentSize experiments and post the results/repro here, maybe i've missed something obvious :)

I agree having it runtime-configurable is definitely more flexible, too.

And, while we're on that -- are there any plans on further improvements in the latency land? I would gladly trade 20% of mutator performance for limiting worst-case latency to 1-3 milliseconds (==games, VR, in-memory databases [databases because 1 blocked request actually raises latency for many requests that got queued during the GC time])

or 50-60% for <10 microseconds (robotics, avionics, packet routing, algorithmic trading, sound processing etc).

Maybe with some cheats like thread-local heaps (blocking 1 thread and having to copy messages across threads is much better than blocking entire server) or something.

Ah, and I'm assuming about 50% heap utilization (live %) and heap sizes around 16 gb ... 1024 gb, and no numbers on allocation rate because currently to deal with these problems you have to avoid allocations like a plague %) but having that luxury would definitely increase developer productivity :)

[Maoni0]

@wizzard0 latency is something we always try to improve. Obviously there are many different scenarios and we have to prioritize our work. If you would like to tell me more details on the product you are working on, I'd be happy to understand the specific scenarios you care about to see what we could do to help. Feel free to email me with some description if you like.

[ghost]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing. Please share any feedback you might have in the linked issue.

[wizzard0]

welll… still relevant!

[Maoni0]

with regions we don't have a limit for NoGC anymore - as long as you have that much memory to commit you can specify as big as a limit as you like. @cshung did the work for regions to support NoGC in .net 7.

[wizzard0]

ah, great! is there a place to read more about those changes? i skimmed notes for .net7 preview in dotnet/core/#7108 and dotnet/runtime/#43844 and had no idea this scenario was affected %)

[Maoni0]

the doc isn't there yet because we just enabled regions in main and the build isn't even out yet. I wanted to wait a bit before we put in the doc change just to be sure that we don't need to revert the regions feature on the off chance that something very unexpected happens.

[wizzard0]

Makes sense. Looking forward for the release then %)

Thank you for the prompt reply!