What's new in .NET 7 Preview 3 [WIP]

[leecow]

What's new in .NET 7 Preview 3

This issue is for teams to highlight work for the community that will release .NET 7 Preview 1

To add content, use a new conversation entry. The entry should include the team name and feature title as the first line as shown in the template below.

## Team Name: Feature title

[link to the tracking issue or epic item for the work]

Tell the story of the feature and anything the community should pay particular attention 
to be successful using the feature.

Preview 1: #7106
Preview 2: #7107
Preview 3: #7108
Preview 4: #7378
Preview 5: #7441
Preview 6: #7454
Preview 7: #7455

[tarekgh]

Observability

• Allow Trace Samplers to Modify the Activity Trace State runtime#65530

    //  ActivityListener Sampling callback
    listener.Sample = (ref ActivityCreationOptions<ActivityContext> activityOptions) =>
    {
        activityOptions = activityOptions with { TraceState = "rojo=00f067aa0ba902b7" };
        return ActivitySamplingResult.AllDataAndRecorded;
    };

[tarekgh]

System.Composition.Hosting

Providing APIs to allow adding a single object instance to the System.Composition.Hosting container. Similar to the functionality provided in the legacy interfaces System.ComponentModel.Composition.Hosting with the API ComposeExportedValue(CompositionContainer, T)

dotnet/runtime#29400

namespace System.Composition.Hosting
{
    public class ContainerConfiguration
    {
        public ContainerConfiguration WithExport<TExport>(TExport exportedInstance);
        public ContainerConfiguration WithExport<TExport>(TExport exportedInstance, string contractName = null, IDictionary<string, object> metadata = null);

        public ContainerConfiguration WithExport(Type contractType, object exportedInstance);
        public ContainerConfiguration WithExport(Type contractType, object exportedInstance, string contractName = null, IDictionary<string, object> metadata = null);
    }
}

[janvorli]

Startup time improvements with Write-Xor-Execute enabled

The dotnet/runtime#65738 reimplemented the precode and call counting stubs (tiered compilation helper stubs) to significantly reduce number of post-creation modifications of executable code in the runtime. This resulted in 10-15% startup time improvements.

As a bonus, this change also resulted in steady state performance improvements (upto 8%) in some microbenchmarks and some ASPNet Benchmarks even without Write-Xor-Execute enabled.

However, there are few regressions resulting from that change too (without Write-Xor-Execute enabled) that will be addressed in the upcoming preview releases. These were observed in the Orchard and Fortunes benchmarks on Intel processors only.

[JulieLeeMSFT]

CodeGen

Community PRs (Many thanks to JIT community contributors!!)

From @clamp03

• Enable Fast Tail Call Optimization for ARM32 Enable Fast Tail Call Optimization for ARM32 runtime#66282

From @SkiFoD

• Optimize "X & 1 == 1" to "X & 1" (#61412) Add optimization "X & 1 == 1" to "X & 1" (#61412) runtime#62818

From @sandreenko

• [crossgen2] Promote single byref aot [crossgen2] Promote single byref aot. runtime#65682

From @SingleAccretion

• Fix missing zero-offset sequences and add checking runtime#64805
• Handle direct addresses for statics in IsFieldAddr runtime#64846
• Do not number partial definitions and ARGPLACE nodes runtime#64898
• Use SSA def descriptors in copy propagation runtime#65250
• ZeroObj assertions runtime#65257
• Deduplicate some HWI codegen code runtime#65302
• Use push for 8/12 byte struct args on x86 runtime#65387
• Do not set GLOB_REF for invariant indirections runtime#65709
• Do not value number locals on the LHS runtime#65902
• Keep the volatility of CLS_VARs in rationalization runtime#65919
• Slightly more aggressive ASG reversal runtime#65920
• Fix copy propagation runtime#66070
• Count OBJ/BLK as memory uses runtime#66135
• Delete compUnsafeCastUsed runtime#66204
• Fix a couple issues with GTF_GLOB_REF setting runtime#66247
• Do not create small constants while morphing cascading addition runtime#66270
• Do not propagate RHS flags in block morphing runtime#66291
• Stop generating CLS_VAR for 64 bit targets runtime#66298
• A better fix for #66242 runtime#66335
• Do not assume containment runtime#66385
• Some small copy propagation changes runtime#66582

Form @trympet

• Treat TZCNT/POPCNT/LZCNT as never negative runtime#64951

From @Wraith2

• Add xarch blsi runtime#66193
• Add flags checks to BMI1 intrinsic lowering runtime#66736

Dynamic PGO

• PGO: Profile isinst/castclass in order to optimize them in Tier 1 PGO: Profile isinst/castclass runtime#65460

Arm64

• Reduced the number of generated instructions for Vector.Create Morph Vector.Create(0) to Vector.Zero runtime#63821 & Allow constant propagation of Vector.Zero. runtime#65028
• Optimize Arm64 comparison instructions: cmle, cmlt, fcmle, fcmlt [JIT] More ARM64 comparison instruction optimizations with Vector.Zero  runtime#64783
• Better addressing mode for floating point on arm64 JIT: better addressing mode for floating point on arm64 runtime#65468
• Optimize a % b ARM64 - Optimizing a % b operations runtime#65535
• JIT: Faster vector == Vector128.Zero on arm64 JIT: Faster vector == Vector128.Zero on arm64 runtime#65632

Loop Optimizations

• Loop Cloning Cloning improvements runtime#66257 improved the duration of single invocation by 21% for System.Collections.Tests.Perf_BitArray.BitArrayLeftShift(Size: 512):
  

General Optimizations

• Eliminate extra copy of struct from a callee that was returned in Hidden Buffer Structs: Do not mark "Hidden buffer pointer" as address-exposed runtime#64130
• Unroll String.Equals and str.StartsWith for constant strings JIT: Unroll Equals and StartsWith for constant strings and spans. [0..32] chars runtime#65288 & Extend Equals/StartsWith auto-vectorization for OrdinalIgnoreCase runtime#66095
• movzx optimization after setcc shows 0.03 ~ 0.16 % code size reduction JIT: Optimize movzx after setcc runtime#66245

[mangod9]

GC Regions Enabled by default

With Preview 3, regions functionality which should help with memory utilization for high throughput applications has been enabled by default. The functionality is now enabled for all Platforms except MacOS and NativeAOT (which would be enabled in the future). More details are available in this issue: dotnet/runtime#43844

We expect some working set increases for smaller applications due to how regions are initially allocated. If you notice any functional or performance differences please create an issue within the runtime repo.

[agocke]

NativeAOT Update

In the .NET 7 Preview 2 blog post, we announced that the NativeAOT project has been moved out of experimental status and into mainline development in .NET 7 in the dotnet/runtime repo. We know that many of you have been eagerly awaiting updates from the team on what’s coming for NativeAOT, and we have a couple of new updates for you for Preview 3!

If you want details about NativeAOT, or to jump in and get started with it, the repo docs are the best place for that.

We also recognize that some of you might not be familiar with what NativeAOT is, so we wanted to share a quick overview of it with you.

What is NativeAOT?

AOT, ahead-of-time compilation, refers to an umbrella of technologies which generate code at application build time, instead of run-time. AOT is not new to .NET Core - we ship ReadyToRun for client and server scenarios, and Mono AOT for Mobile and WASM. NativeAOT brings full native pre-compilation to .NET Core desktop client and server scenarios. NativeAOT is not replacing these existing technologies, rather offering a new set of capabilities that unlocks new form factors.

Existing AOT-compiled .NET assemblies contain platform-specific data structures and native code to frontload work typically done at runtime. Precompiling these artifacts saves time at startup (e.g. ReadyToRun), and enables access to no-JIT platforms (e.g. iOS). If precompiled artifacts are not present, .NET either falls back to JIT or interpretation (depending on the platform).

NativeAOT is similar to .NET Core’s existing AOT technologies, but it produces only native artifacts. In fact, the NativeAOT runtime does not know how to read the .NET assembly file formats - everything is platform-native; the executable file format parsing is fully handled by the underlying operating system.

The main advantage of NativeAOT is in startup time, memory usage, accessing to restricted platforms (no JIT allowed), and smaller size on disk. Applications start running the moment the operating system pages in them into memory. The data structures are optimized for running AOT generated code, not for compiling new code at runtime. This is similar to how languages like Go, Swift, and Rust compile. NativeAOT is best suited for environments where startup time matters the most. Targeting NativeAOT has stricter requirements than general .NET Core applications and libraries. NativeAOT forbids emitting new code at runtime (e.g. Reflection.Emit), and loading new .NET assemblies at runtime (eg. plug-in models).

Prepare your apps for NativeAOT

For .NET 7 we are targeting console apps and native libraries as the primary scenario for NativeAOT. Application developers and library authors can now take advantage of NativeAOT by ensuring that their applications are trimmable. Since trimming is a requirement for NativeAOT compilation, preparing your applications and libraries now for trimming will help them get ready for NativeAOT as well. If you are an author of any .NET libraries, following the “Trimming libraries” instructions specifically will help you prepare your libraries for trimming and NativeAOT.

One of the apps that we're planning to ship in .NET 7 compiled with NativeAOT is the crossgen tool. Crossgen is part of the .NET SDK - it's the CoreCLR AOT compiler that produces ReadyToRun executables. Crossgen is written in C# and we currently ship it compiled with itself as a ReadyToRun app (it's turtles all the way down!). We're already seeing some very promising numbers in terms of compilation speed and size. Crossgen benefits heavily from NativeAOT because it's a short-lived process and the startup overhead dominates the overall execution time:

Scenario	ReadyToRun	NativeAOT
Compile CoreLib	4182 ms	3512 ms
Compile HelloWorld	185 ms	49 ms

Configuration	Size
ReadyToRun	34.8 MB
NativeAOT	17.6 MB

Looking ahead, NativeAOT compatibility will be improved over the next few versions of .NET, however there will always be reasons to prefer JIT for many scenarios. We will also add first-class support in the dotnet SDK for publishing projects with NativeAOT.

[sajjadarashhh]

thanks to .net team for amazing features in each update.
i have one question we can use nativeAot in blazor wasm!?

[srxqds]

thanks to .net team for amazing features in each update. i have one question we can use nativeAot in blazor wasm!?

i think it can't got from this dotnet/runtime#45471 (comment)

[bartonjs]

Cryptography: Generating X.500 names more robustly

dotnet/runtime#44738

Classically, anyone wanting to build a X.500 name (such as for creating test certificates with the CertificateRequest class did so with string manipulation, either via a simple literal or with string formatting, e.g.

request = new CertificateRequest($"CN={subjectName},OU=Test,O=""Fabrikam, Inc.""", ...);

This is generally fine, except for when subjectName contains a comma, quote, or anything else that has an influence on the parser. To address that, we added the X500DistinguishedNameBuilder class. Because every method only operates on a single relative distinguished name (RDN), there's no ambiguity in parsing. As a bonus, since the RDN identifiers are expanded, you no longer have to guess what "CN" stands for ("Common Name").

X500DistinguishedNameBuilder nameBuilder = new();
nameBuilder.AddCommonName(subjectName);
nameBuilder.AddOrganizationalUnitName("Test");
nameBuilder.AddOrganizationName("Fabrikam, Inc.");

request = new CertificateRequest(nameBuilder.Build(), ...);

[bartonjs]

Cryptography: EventSource for X509Chain on Linux

• Add tracing to the Linux X509Chain implementation runtime#65860

X.509 certificate chain building has a lot of pieces and moving parts. While it reports detailed reasons for failure as part of the API, sometimes it's useful when diagnosing issues to see when something happened, or how long it took, et cetera. On Windows the logging is done by the OS, as part of "CAPI2 Diagnostics", but on Linux we had no equivalent. Starting in .NET 7 Preview 3 the traces are produced by the System.Security.Cryptography.X509Certificates.X509Chain.OpenSsl event source. These two collected trace runs, at full verbosity, show the performance benefit of caching certificate revocation lists (CRLs) during chain building operations.

2022-04-11T16:05:24.164Z: ChainStart - Starting X.509 chain build.
2022-04-11T16:05:24.344Z: FindFirstChainFinished - First build finished with status 0.
2022-04-11T16:05:24.352Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2022-04-11T16:05:24.379Z: CrlIdentifiersDetermined - Certificate 'CN=microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl', will use '12fa6c3e.efbe5079.crl' as the cache file.
2022-04-11T16:05:24.380Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:24.412Z: CrlCacheExpired - The cached CRL's nextUpdate value (2022-04-11T09:05:23.9500496-07:00) is not after the verification time (2022-03-27T14:28:22.0000000-07:00).
2022-04-11T16:05:24.414Z: CrlCacheCheckStop - Duration 33.851ms
2022-04-11T16:05:24.433Z: AssetDownloadStart - Starting download of certificate asset uri 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl' with a 15000ms timeout.
2022-04-11T16:05:24.700Z: AssetDownloadStop - Asset download finished with a 1249-byte response. - Duration 267.098ms
2022-04-11T16:05:24.760Z: CrlCacheWriteSucceeded - The downloaded CRL was successfully written to the cache.
2022-04-11T16:05:24.760Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2022-04-11T16:05:24.760Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:24.777Z: CrlCacheExpired - The cached CRL's nextUpdate value (2022-04-11T09:05:23.9500496-07:00) is not after the verification time (2022-04-06T12:54:50.0000000-07:00).
2022-04-11T16:05:24.778Z: CrlCacheCheckStop - Duration 17.566ms
2022-04-11T16:05:24.778Z: AssetDownloadStart - Starting download of certificate asset uri 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl' with a 15000ms timeout.
2022-04-11T16:05:24.814Z: AssetDownloadStop - Asset download finished with a 877-byte response. - Duration 36.113ms
2022-04-11T16:05:24.843Z: CrlCacheWriteSucceeded - The downloaded CRL was successfully written to the cache.
2022-04-11T16:05:24.847Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2022-04-11T16:05:24.848Z: RevocationCheckStop - Duration 496.299ms
2022-04-11T16:05:24.852Z: ChainStop - Duration 688.635ms

2022-04-11T16:05:50.392Z: ChainStart - Starting X.509 chain build.
2022-04-11T16:05:50.572Z: FindFirstChainFinished - First build finished with status 0.
2022-04-11T16:05:50.580Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2022-04-11T16:05:50.608Z: CrlIdentifiersDetermined - Certificate 'CN=microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl', will use '12fa6c3e.efbe5079.crl' as the cache file.
2022-04-11T16:05:50.609Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:50.625Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2022-04-21T06:28:22.0000000-07:00) is acceptable, using the cached file.
2022-04-11T16:05:50.626Z: CrlCacheCheckStop - Duration 17.139ms
2022-04-11T16:05:50.633Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2022-04-11T16:05:50.633Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:50.633Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2022-04-27T13:40:47.0000000-07:00) is acceptable, using the cached file.
2022-04-11T16:05:50.633Z: CrlCacheCheckStop - Duration 0.177ms
2022-04-11T16:05:50.635Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2022-04-11T16:05:50.635Z: RevocationCheckStop - Duration 54.661ms
2022-04-11T16:05:50.637Z: ChainStop - Duration 245.381ms

[kouvel]

System.Threading

• Add support for Windows IO completions to the portable thread pool runtime#64834

The managed implementation of the thread pool is now used by default for handling IO completions on Windows. IO completions are queried in batches on fewer threads, which can be a bit more efficient, and are processed at higher priority in the same worker thread pool to reduce oversubscription.

If SocketTransportOptions.UnsafePreferInline is being used, that can be worked around after this change by also using DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS=1 as described there.

The previous implementation of IO completion handling can be restored by setting the environment variable DOTNET_ThreadPool_UsePortableThreadPoolForIO=0 before starting the app.

[AustinWise]

System.Threading

* [Add support for Windows IO completions to the portable thread pool runtime#64834](https://github.com/dotnet/runtime/pull/64834)

This appears to have not made it into the blog post. The only mention of the new threadpool features I could find on the blog was in the performance improvements post. And this issue is the only hit on Google for the new DOTNET_ThreadPool_UsePortableThreadPoolForIO config.

Should this change be documented or publicized like how the portable thread pool was announced in the blog post for .NET 6 preview 1? It's a cool feature!

[leecow]

.NET 7 GA is available. Closing these pre-release issues.