Remove some GCHandles from SendHeaders()

[AaronRobinsonMSFT]

Description

Fixes #40215

This introduces a new type, UnmanagedBufferAllocator, that manages unmanaged block allocations. The intent here is to remove the allocation of handles and temporary managed arrays and replace them with native memory.

Instead of using an unmanaged memory allocator like NativeMemory, the GC.AllocateUninitializedArray() could be used to create pinned memory. I've rejected this because it puts the onus on the GC to collect the memory whereas with the unmanaged memory it can be freed precisely when it is no longer needed. Since the pinned heap is presently considered only on a gen2 collection it leaves this unused memory around far longer than needed and creates unnecessary pressure.

[AaronRobinsonMSFT]

/benchmark list

[pr-benchmarks]

Crank Pull Request Bot

/benchmark <benchmarks[,...]> <profiles[,...]> <components,[...]>

Benchmarks:

• plaintext: TechEmpower Plaintext Scenario - ASP.NET Platform implementation
• json: TechEmpower JSON Scenario - ASP.NET Platform implementation
• fortunes: TechEmpower Fortunes Scenario - ASP.NET Platform implementation
• yarp: YARP - http-http with 10 bytes
• mvcjsoninput2k: Sends 2Kb Json Body to an MVC controller

Profiles:

• aspnet-perf-lin: INTEL/Linux 12 Cores
• aspnet-perf-win: INTEL/Windows 12 Cores
• aspnet-citrine-lin: INTEL/Linux 28 Cores
• aspnet-citrine-win: INTEL/Windows 28 Cores
• aspnet-citrine-arm: ARM/Linux 32 Cores
• aspnet-citrine-amd: AMD/Linux 48 Cores

Components:

• kestrel
• mvc

[davidfowl]

Http.sys isn't in this list. I recently did a perf change to http.sys and had to build locally and run a benchmark. We should add the JSON one.

cc @sebastienros @adityamandaleeka @Tratcher

[jkotas]

LGTM!

[AaronRobinsonMSFT]

@davidfowl @Tratcher @JamesNK Please take another look. The CI is all green.

[davidfowl]

So, it's a bit slower or a wash and the GC numbers look about the same. 🤔

[AaronRobinsonMSFT]

Sharing offline comments I made based on collection of a nettrace for GCHandle usage.

I'm convinced on this change. The logging itself is a win. The number of GCHandle events is staggering. I did a quick experiment locally. Instead of using NativeMemory.Alloc and NativeMemory.Free, I replaced them with ArrayPool<byte>.Shared.Rent and a pinned GCHandle. The trace resulted in precisely the same experience before my larger changes. This is a win and the performance characteristics that we've improved aren't reflected in the crank base statistics. They are however reflected in nettrace.

The nettrace impact is prior to this change the nettrace was 1GB, but after this change it is approximately 40MB. The win here is reduction of the impact of GCHandle events.

[davidfowl]

@sebastienros I want to assign this to you. Once we have benchmarks running on .NET 8 we should merge this.

[sebastienros]

@davidfowl we are tracking net8.0 now (check the charts) so I assume that's what you wanted before we merge the PR.

[davidfowl]

Yep

[BrennanConroy]

The nettrace impact is prior to this change the nettrace was 1GB, but after this change it is approximately 40MB. The win here is reduction of the impact of GCHandle events.

Could you share what nettrace args are needed to show this? I'm thinking ahead to next year when we write a ASP.NET Core 8 perf improvements blog post and it's useful to have info on the PR so we don't need to figure out how to repro things a year later.

[AaronRobinsonMSFT]

@BrennanConroy This is easy to see by adding the following arguments to the crank command: --application.dotnetTrace true --application.dotnetTraceProviders gc-verbose. Running scenarios where a lot of GCHandles instance are created/destroyed will saturate the pipeline and result in dropped events or at best, very large nettrace files.