Aging dependent handles

[VSadov]

We do not age dependent handles like all other kinds of handles. As a result dependent handles stay in Gen 0 and get visited on every GC. That is unnecessary work when dependent handles refer to tenured objects, which is a common case.

This change enables aging of dependent handles (and rejuvenation, when needed).

[ghost]

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

Issue Details

---

We do not age dependent handles like all other kinds of handles. As a result dependent handles stay in Gen 0 and get visited on every GC. That is unnecessary work when dependent handles refer to tenured objects, which is a fairly common case.

This change enables aging of dependent handles (and rejuvenation, when needed).

Author:	VSadov
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[Maoni0]

what kind of testing has been done on this?

[VSadov]

what kind of testing has been done on this?

I think regular libraries tests are sensitive enough to this change.

There are two parts in the change:

• the actual aging is very simple and works exactly the same as with other kinds of handles. I do not think this can go wrong. Aging is optional - even if we do not age, nothing bad will happen. And aging is conservative - it just increases the age of the handle as it is visited by GC, it does not need to look at the referenced objects as they get checked/aged in the same GC cycle.

• the rejuvenation is precise and thus is more delicate.
  Unlike with ordinary handles, we also need to look at the generation of the secondary object, in case it is younger than the primary. This is the same approach as with async pinned handles where the age of the handle is assumed to be the minimum of the ages of all objects it refers to.
  If I intentionally do not consider the secondary object in the age computation, many libraries tests fail. Some tests like System.Text.RegularExpressions fail 100% consistently. I think we have sufficient coverage for rejuvenation scenario.

[VSadov]

I think I can run System.Text.RegularExpressions test in a loop 100 times, in Release and Checked configurations - with Server GC to be sure.

That will be a few hours of stress, so it may take a while.

[Maoni0]

I'm much more worried about the possibility of this causing a heap corruption which could easily take weeks to debug. do you have a real customer workload (that's not a simple test) that uses dependent handles that demonstrate the perf benefits? the problem with little tests is you could run it for hours but due to the simple patterns it generates, longer testing will not show more problems.

[VSadov]

do you have a real customer workload (that's not a simple test) that uses dependent handles that demonstrate the perf benefits?

Similarly to other handle kinds, reducing dependent handle scans should be a win, but, no, I do not have an actual app that demonstrates the benefits.

[Maoni0]

DHs are a lot more intricate than other handle types and our testing there is not great. so I would not consider doing this now - the amount of risk it brings does not justify the code churn.

[VSadov]

The change does not touch the "tricky" parts of dependent handles. The iterative tracing is tricky. This is in handle aging, which is simple. There is no need for a handle to be Gen-N when the objects it represents are older than Gen-N.
It looks like someone just missed to add dependent handle kind in the methods that update the handle ages. This early in release cycle could be a good time to fix issues like this.

[cshung]

do you have a real customer workload (that's not a simple test) that uses dependent handles that demonstrate the perf benefits?

Similarly to other handle kinds, reducing dependent handle scans should be a win, but, no, I do not have an actual app that demonstrates the benefits.

We do have a scenario where not aging DependentHandle is causing a problem here.

[VSadov]

One thing that @cshung asked me to mention, as another data point, is that NativeAOT uses dependent handles extensively.

Since the runtime is mostly managed code, DependentHandle or ConditionalWeakTable it is a logical choice when arbitrary objects need to be augmented with some additional data (monitor locks, COM info, marshalling stubs, etc..).

This does not mean that every NativeAOT program uses a lot of dependent handles. The uses are pay-for-play, so some small programs may not create any.
It is however likely that real-world size NativeAOT programs will use some dependent handles. I.E. blocking on a monitor lock will result in a Lock object referenced via a dependent handle.

====== A few examples where NativeAOT runtime uses dependent handles.

In Monitor Locks:

runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/SyncTable.cs

Line 94 in 118a162

DependentHandlehandle=newDependentHandle(obj,collector);

In Monitor Conditions:

runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Monitor.NativeAot.cs

Line 27 in b59c649

privatestaticConditionalWeakTable<object,Condition>s_conditionTable=newConditionalWeakTable<object,Condition>();

In COM interop:

runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Runtime/InteropServices/ComWrappers.NativeAot.cs

Line 32 in 8918adf

privatereadonlyConditionalWeakTable<object,ManagedObjectWrapperHolder>_ccwTable=newConditionalWeakTable<object,ManagedObjectWrapperHolder>();

In PInvoke delegate thunks

runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Runtime/InteropServices/PInvokeMarshal.cs

Line 75 in 98a89c9

privatestaticConditionalWeakTable<Delegate,PInvokeDelegateThunk>s_pInvokeDelegates;

[VSadov]

Per offline discussion - with all the ongoing work and investigations in GC area, this is not something that GC team would be comfortable with taking at the moment.

We can track this as an issue for some future milestone.

[VSadov]

@EgorBot -amd -intel -arm

usingSystem;usingSystem.Runtime;usingBenchmarkDotNet.Attributes;// Benchmark for https://github.com/dotnet/runtime/pull/78746 — "Aging dependent handles".//// Pathology this PR fixes:// Dependent handles never age, so they stay in Gen 0 and get visited on every// ephemeral GC, even when their primary/secondary objects are already in Gen 2.//// Setup:// * Allocate N DependentHandles with a strongly-rooted primary and a small secondary.// * Force 3 blocking Gen 2 collections so everything tenures to Gen 2.// (Post-PR the handles also age; pre-PR they stay at age 0 forever.)//// Measure:// * Cost of one forced Gen 0 / Gen 1 / Gen 2 collection.//// Expected post-PR delta:// * ForcedGen0, ForcedGen1: large speedup; cost should become ~independent of N.// * ForcedGen2: roughly flat (Gen 2 already scanned dependent handles).[MemoryDiagnoser][GcServer(true),GcConcurrent(false)]publicclassDependentHandleAging{privateobject[]?_keys;privateDependentHandle[]?_handles;[Params(100_000,1_000_000)]publicintN;[GlobalSetup]publicvoidSetup(){_keys=newobject[N];_handles=newDependentHandle[N];for(inti=0;i<N;i++){// Key is strongly rooted by the _keys array so the DH entry stays live.objectkey=new();_keys[i]=key;_handles[i]=newDependentHandle(key,newbyte[16]);}// Tenure handles + referents to Gen 2 (this is the scenario the PR targets).for(inti=0;i<3;i++){GC.Collect(2,GCCollectionMode.Forced,blocking:true,compacting:true);GC.WaitForPendingFinalizers();}// Sanity check: the primaries should be in Gen 2 before measurement starts.intgen=GC.GetGeneration(_keys[0]);if(gen!=GC.MaxGeneration)thrownewInvalidOperationException($"Setup did not tenure to Gen{GC.MaxGeneration}; got Gen{gen}.");}[GlobalCleanup]publicvoidCleanup(){if(_handlesisnull)return;for(inti=0;i<_handles.Length;i++)_handles[i].Dispose();_handles=null;_keys=null;}// Pre-PR: must visit every dependent handle (they're stuck in Gen 0).// Post-PR: handles aged to Gen 2 -> Gen 0 GC skips them entirely.[Benchmark]publicvoidForcedGen0()=>GC.Collect(0,GCCollectionMode.Forced,blocking:true);// Same pathology as Gen 0 — ephemeral GCs scan dependent handles pre-PR.[Benchmark]publicvoidForcedGen1()=>GC.Collect(1,GCCollectionMode.Forced,blocking:true);// Control: Gen 2 always scans dependent handles, so this should be ~unchanged// (or fractionally slower because rejuvenation now looks at the secondary too).[Benchmark]publicvoidForcedGen2()=>GC.Collect(2,GCCollectionMode.Forced,blocking:true);}

[VSadov]

On the microbenchmark, depending on number of dependent handles we can spend 10X to 30X less time in GC pauses.

With this change, ephemeral GCs get practically insensitive to the quantity of the handles.
As the objects that are referenced are promoted to higher generations, the handles also aged and thus skipped in bulk in handle scanning.
(there is still cost in Gen2, as the handles and objects they refer to are still there)

Results for ubuntu24_azure_emeraldrapids

@VSadov

BenchmarkDotNet v0.15.8, Linux Ubuntu 24.04.4 LTS (Noble Numbat)
INTEL XEON PLATINUM 8573C 2.30GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK 11.0.100-preview.6.26311.113
[Host] : .NET 10.0.9 (10.0.9, 10.0.926.27113), X64 RyuJIT x86-64-v4
Concurrent=False Server=True 

Method	Toolchain	N	Mean	Error	Ratio	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
ForcedGen0	PR #78746**	100000	142.6 μs	1.78 μs	1.00	1000.0000	-	-	-	NA
ForcedGen0	main	100000	1,552.2 μs	10.53 μs	10.88	1000.0000	-	-	-	NA
ForcedGen1	PR #78746	100000	150.4 μs	1.12 μs	1.00	1000.0000	1000.0000	-	-	NA
ForcedGen1	main	100000	1,554.1 μs	5.61 μs	10.33	1000.0000	1000.0000	-	-	NA
ForcedGen2	PR #78746	100000	3,543.3 μs	48.23 μs	1.00	1000.0000	1000.0000	1000.0000	109 B	1.00
ForcedGen2	main	100000	3,567.9 μs	48.16 μs	1.01	1000.0000	1000.0000	1000.0000	96 B	0.88
ForcedGen0	PR #78746**	1000000	437.4 μs	8.74 μs	1.00	1000.0000	-	-	-	NA
ForcedGen0	main	1000000	13,014.5 μs	24.84 μs	29.78	1000.0000	-	-	-	NA
ForcedGen1	PR #78746	1000000	432.8 μs	8.50 μs	1.00	1000.0000	1000.0000	-	-	NA
ForcedGen1	main	1000000	13,024.3 μs	40.48 μs	30.13	1000.0000	1000.0000	-	-	NA
ForcedGen2	PR #78746	1000000	27,114.2 μs	519.39 μs	1.00	1000.0000	1000.0000	1000.0000	116 B	1.00
ForcedGen2	main	1000000	27,248.0 μs	542.15 μs	1.01	1000.0000	1000.0000	1000.0000	105 B	0.91

Full logs

[VSadov]

what kind of testing has been done on this?

Satori has this fix for a few years now. There were numerous stress runs and investigations for unrelated bugs since then. This fix was never causing trouble and now seems an unnecessarily diff between two GCs.

I highly suspect it was never intentional to have an age-less handle in a generational GC and it may be just a result of some typo or mismerge.

Perhaps it is time to merge this in main?

[VSadov]

.

[jkotas]

Perhaps it is time to merge this in main?

Sounds good to me.

@janvorli@kkokosa PTLA

[mangod9]

We do not age dependent handles like all other kinds of handles. As a result dependent handles stay in Gen 0 and get visited on every GC. That is unnecessary work when dependent handles refer to tenured objects, which is a common case.

This change enables aging of dependent handles (and rejuvenation, when needed).

was there an original reason for not aging dependent handles?

[VSadov]

We do not age dependent handles like all other kinds of handles. As a result dependent handles stay in Gen 0 and get visited on every GC. That is unnecessary work when dependent handles refer to tenured objects, which is a common case.
This change enables aging of dependent handles (and rejuvenation, when needed).

was there an original reason for not aging dependent handles?

I can’t think of a reason to do this intentionally.

[kkokosa]

Well, I can't think of any reason either. Please let me settle in a little before I express my final opinion.

[janvorli]

/ba-g the failure is #129329

[VSadov]

Thanks!