[release/8.0-preview5] Ensure ComponentState is always disposed #48410
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #48406 to release/8.0-preview5
/cc @SteveSandersonMS
Ensure ComponentState is always disposed
Updates the component disposal logic to ensure that
ComponentState
is always disposed, and henceArrayBuilder
instances are always disposed, and hence we always return the underlying buffers to the pool.Description
Without this, the pooling of
ArrayBuilder
-held arrays becomes ineffective because the pools become full, and then the behavior switches over to transient instances, reverting to regular GC behavior.Fixes #48411
Customer Impact
This fix will significantly reduce GC pressure because the
RenderTreeFrame[]
instances are large. In one test, after 20 requests, we had allocated 57MB ofRenderTreeFrame[]
instances. This is not a leak, but it does cause the GC to work harder because more memory is being allocated quickly and hence collections must occur more frequently.The fix causes pooling to work correctly so that even though the same amount of
RenderTreeFrame[]
storage is needed, it will be able to reuse the same storage across requests so in most cases it won't trigger any GC pressure.Regression?
The issue has been present since 2019.
Risk
Low because this is a 8.0 preview release, we have tests, and several people have reviewed this code.
Verification
Packaging changes reviewed?