Pool Deflater instances to reuse native compression state

[Copilot]

Short-lived compressors repeatedly allocate and free large native deflate state. This change adds a bounded pool of native compression states, reusing matching states through the existing native reset operation.

• Reuse: retain up to eight idle states across all configurations, matched by compression level, strategy, window bits, and memory level. Deflater wrappers remain single-lifetime; only their native state is pooled.
• Ownership: release input pins and clear I/O pointers before returning state. Reset native state before reuse, discarding unusable state on reset failure.
• Replacement: when full, rotate the eviction slot so the pool can adapt to changing configurations. Native creation, reset, and eviction disposal remain outside the pool lock.
• Retention: the capacity bounds idle cached states, not active compressors or total process memory. The source documents an approximate 2.6 MiB idle-state budget; this is an estimate, not a measured retained-memory result.
• Coverage: sequential native-state reuse, compression-setting separation, pool replacement/adaptation, simultaneous ownership, reuse after destination failures, concurrent rent/return round trips, and unconditional batch cleanup.

Validation

Local Windows x64 Release build completed with zero warnings and errors. All 7 focused pool tests, 2,659 default System.IO.Compression tests, and 367 default System.IO.Compression.ZipFile tests passed. Default suites exclude OuterLoop and failing categories. Other platforms were not exercised locally.

Performance and accepted tradeoff

The local reproduction uses the seeded 5,000-byte, half-random input from #134700. Baseline Deflater source from 084d619 and the revised implementation were built and run in separate private CoreRun hosts with the same runtime and native library; the hosts differed only in System.IO.Compression.dll. These are patch-before/after measurements, not a direct .NET 8 versus .NET 10 comparison.

Warm runs used 2,000 warm-up operations followed by 20,000 measured operations. Median elapsed time across three repetitions:

Fixed-configuration workload	Baseline	Eight-slot pool	Improvement
DOP 8	290.7 ms	162.9 ms	44%
DOP 12	279.5 ms	125.0 ms	55%

Process page faults per operation fell from 9.394 to 0.033 at DOP 8 and from 11.329 to 0.046 at DOP 12. Native allocation/reset call counts were not instrumented.

Known limitation: a synthetic workload cycling 12 configurations (four compression levels across Deflate, GZip, and ZLib) exceeds the eight-slot working set. At DOP 4, five additional paired runs confirmed median warm elapsed time increased from 258.3 ms to 332.1 ms, a 28.5% slowdown. Pooling is not a universal throughput improvement.

A 16-slot candidate reduced the synthetic churn but gave no consistent additional benefit for the original fixed-configuration workload, doubled the estimated idle native-memory budget to 5.2 MiB, and did not eliminate over-capacity slowdowns. Retain eight slots and accept this documented limitation rather than add adaptive admission, per-key pools, trimming, or more synchronization machinery. These local measurements are workload-specific, not universal performance guarantees.

Resolves #134788

Note

This description and the follow-up test improvements were prepared with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.