Preparing for the .NET 10 GC

C# is a lot better than Java on this front since they support stack allocated structs

In this case, we're discussing a case where mark-and-sweep is used to collect cyclic references, and it's implied that there are no generations. (Because otherwise, purely relying on reference counting means that cyclic references end up leaking unless things like weak references are used.)

IE, the critical difference is that reference counting frees memory immediately; albeit at a higher CPU cost and needing to still perform a mark-and-sweep to clear out cyclic references.

One of the main problems with refcounting is that unless your compiler/JIT are able to safely, aggressively optimize out reference increment/decrements, you can spend a ton of CPU time pointlessly bumping a counter up and down every time you enter a new function/method. This has been a problem for ObjC and Swift applications in the past AFAIK, though both of those compilers do a great job of optimizing that stuff out where possible.

There are some other things that would probably be improvements coming along with refcounting though - you might be able to get rid of GC write barriers.

For the author, some definitions:

GC? -- Maybe "Garbage Collection", i.e., have some memory (mainly computer main memory) allocated, don't need it (just now or forever), and want to release it, i.e., no longer have it allocated for its original purpose. By releasing can make it available for other purposes, software threads, programs, virtual machines, etc.

DATAS? -- Not a spelling error or about any usual meaning for data and instead is as in

https://learn.microsoft.com/en-us/dotnet/standard/garbage-co...

for "Dynamic adaptation to application sizes"

So, we're trying to take actions over time in response to some inputs that are in some respects unpredictable.

Okay, what is the objective, i.e., the reason, what we hope to gain, or why bother?

And for the part that is somewhat unpredictable over time, that's one or more stochastic processes (or one multidimensional stochastic process?).

So, in broad terms, we are interested in stochastic optimal control. "Dynamic adaptation", is close and also close to one method, dynamic programming -- in an earlier thread at Hacker News, gave a list of references. Confession, wrote my applied math Ph.D. dissertation in that subject.

Hmm, how to proceed??? Maybe, (A) Know more about the context, e.g., what the computer is doing, what's to be minimized or maximized. (B) Collect some data on the way to knowing more about the stochastic processes involved.

For me, how to get paid? If tried to make a living from applied stochastic optimal control, would have died from starvation. Got the Ph.D. JUST to be better prepared as an employee for such problems and had to learn that NO one, not even one in the galaxy, cares as much as one photon of ~1 Hz light.

So, am starting a business heavily in computing and applied math. The code from Microsoft tools is all in .NET, ASP.NET, ADO.NET, etc. Code runs fine. The .NET software, via the VB.NET syntactic sugar, is GREAT for writing the code.

So, MUST keep up on Microsoft tools, and here just did that. Since .NET 10 is changing some versions of Windows, my reaction is (i) add a lot of main memory until GC is nearly irrelevant, (ii) in general, wait a few years to give Microsoft time to fix problems, i.e., usually be a few years behind the latest versions, i.e., to "Prepare for .NET 10", first wait a few years.

Experience: At one time, saw some server farms big on reliability. One site had two of everything, one for the real work and another to test the latest for bugs before being used for real work. Another had their own electrical power, Diesel generators ~30 feet high, a second site duplicating everything, ~400 miles away, with every site with lots of redundancy. In such contexts, working hard and taking risks trying to save money on main memory seem unwise.

Some translations for acronyms and terms from this post (sourced from the glossary in dotnet/runtime along with source code grepping):

GC: Garbage Collector

DATAS: Dynamic adaptation to application sizes

UOH: User Old Heap. I can't find an explanation for what this is.

LOH: Large Object Heap. This is where allocations over a size threshold go in .NET.

POH: Pinned Object Heap. Pinning is used to stop an object in the GC's memory from being moved around by the GC (for compaction).

ASP.net: Active Server Pages for .NET. This is a framework for building web applications using .NET, a successor to the classic ASP which was built on COM and scripting languages like JScript/VBScript.

Workstation / Server GC: .NET has two major GC modes which have different configurations for things like having per-cpu-core segregated heaps, doing background or foreground GCs, etc. This is designed to optimize for different workloads, like running a webserver vs a graphical application.

Ephemeral GC / Ephemeral generation: To quote the docs:

> For small objects the heap is divided into 3 generations: gen0, gen1 and gen2. For large objects there's one generation – gen3. Gen0 and gen1 are referred to as ephemeral (objects lasting for a short time) generations.

Essentially, generation 0 or gen0 is where brand new objects live. If the GC sees that gen0 objects have survived when it does a collection, it promotes them to gen1, and then they will eventually get promoted to gen2. Most temporary objects live and die in gen0.

Pause time: Most garbage collectors will need to pause the whole application in order to run, though they may not need the application to stay paused the whole time they are working. So pause time and % pause time track how much time the application spends paused for the GC to do its job; ideally these values are low.

BCD: Quoting the post:

> 1) introduced a concept of “Budget Computed via DATAS (BCD)” which is calculated based on the application size and gives us an upper bound of the gen0 budget for that size, which can approximate the generation size for gen0

Essentially, this is an estimate of how much space the ephemeral generation (temporary objects plus some extras) is using.

TCP: Quoting the post again:

> 2) within this upper bound, we can further reduce memory if we can still maintain reasonable performance. And we define this “reasonable performance” with a target Throughput Cost Percentage (TCP). This takes into consideration both GC pauses and how much allocating threads have to wait.