Stub Precode variant for DynamicHelpers

[davidwrighton]

Run DynamicHelpers logic with StubPrecodes instead of dynamically generating the stubs.

Performance measurements indicate that this path is about 1% faster than the current approach for startup of my powershell benchmark, and results seem similar between X64 and Arm64 which was a surprise to me. Throughput results look like roughly a wash. I'd like to merge this PR in with its current state of changing all Arm64 and X64 behavior to use the new path to get a full set of performance data, as it appears this might just be a better approach than generating stubs dynamically.

• Does it basically work?
• Port assembly to Arm64, Unix and Windows
• Port assembly to X64 Unix
• Perf test startup ... probably on Linux arm64
• Perf test throughput impact (ASP.NET Benchmarks appear mostly unaffected)

[dotnet-policy-service]

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

[steveisok]

/cc @dotnet/area-type-system-and-startup

[Copilot]

Copilot reviewed 17 out of 17 changed files in this pull request and generated no comments.

[janvorli]

LGTM, thank you!

[jkotas]

This will work for iOS and the startup improvement is nice side-effect. I don't see how it is going to work for wasm and potentially other architectures where low-level tricks like this are not possible.

As I have mentioned offline, we may want to use fixups that run before the method executes as the most portable solution. I expect that it would come with similar startup improvement as side-effect, and it would have a lot less arch-specific code.

[davidwrighton]

@jkotas I agree, although I also see ways to make this work in wasm (with some unfortunate bloat in file size). I suspect that just dealing with fixups will be fundamentally better for most paths in wasm, and probably even for iOS, but this path will work well in the short term, and didn't require any significant refactorings (and thus was surprisingly cheap to implement).