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.
Good guide. I _think_ UOH is “unpinned object heap”, which is a variant of the large object heap that allows compaction. So the only things going into the LOH these days are both large and pinned. But I’m not 100% on this.
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.