Introduce static methods to allocate and throw key exception types.

[geeknoid]

EDITED 03/06/2021 by @stephentoub to add revised proposal:

public class ArgumentNullException
{
+    public static void ThrowIfNull([NotNull] object? argument, [CallerArgumentExpression("argument")] string? argumentName = null);
}

Background and Motivation

The .NET ecosystem uses extensive argument checking to improve code reliability and predictability. These checks have a substantial impact on code size and often dominate the code for small functions and property setters. This in consumes more RAM, takes more time to JIT, prevents inlining, and most important it causes substantial instruction cache pollution. Ultimately, the presence of these checks slows code down.

Many libraries, including the framework libraries themselves, implement exception throwing helpers to compensate for this bloat. These simple static functions centralize the exception creation and throwing logic. Why not enshrine this pattern in the exception API surface to encourage smaller/faster code, and avoid library authors having to create these stubs themselves?

Proposed API

I propose that the core framework ArgumentXXXException classes be augmented with static functions responsible for both allocating and throwing the exceptions:

public class ArgumentNullException : ArgumentException
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static void Throw(string paramName) =>
        throw new ArgumentNullException(nameof(paramName));
}

There would be one static method corresponding to each constructor signature of the exception type.

This pattern would be warranted for any exception type that has a sufficiently large usage footprint. Certainly the ArgumentXXXException types would qualify for this, perhaps a few others.

Usage Examples

With such functions, the following code

public void DoSomething(Foo foo)
{
    if (foo == null) throw new ArgumentNullException(nameof(foo));
}

would become

public void DoSomething(Foo foo)
{
    if (foo == null) ArgumentNullException.Throw(nameof(foo));
}

Analyzer and Fixer or Compiler Voodoo

It would be trivial to include an analyzer and associated fixer to upgrade a code base to the new approach, thus encouraging a rapid migration.

Alternatively, the C# compiler could potentially be upgraded to automatically replace canonical uses into calls to the static method which wouldn't require any code changes to yield the perf benefits.

Generated Code

The code required to create and throw an exception costs > 70 bytes of instructions. Here is an example null check compiled in release mode for .NET 5:

00007FFADA6D510B 48837D1800           cmp     qword ptr [rbp+18h],0
00007FFADA6D5110 7541                 jne     short LBL_0
00007FFADA6D5112 48B980C974DAFA7F0000 mov     rcx,offset methodtable(System.ArgumentNullException)
00007FFADA6D511C E83F26B25F           call    CORINFO_HELP_NEWSFAST
00007FFADA6D5121 488945A0             mov     [rbp-60h],rax
00007FFADA6D5125 B901000000           mov     ecx,1
00007FFADA6D512A 48BA70DB88DAFA7F0000 mov     rdx,7FFADA88DB70h
00007FFADA6D5134 E8C7B3C45F           call    CORINFO_HELP_STRCNS
00007FFADA6D5139 48894598             mov     [rbp-68h],rax
00007FFADA6D513D 488B5598             mov     rdx,[rbp-68h]
00007FFADA6D5141 488B4DA0             mov     rcx,[rbp-60h]
00007FFADA6D5145 E8D61BFEFF           call    System.ArgumentNullException..ctor(System.String)
00007FFADA6D514A 488B4DA0             mov     rcx,[rbp-60h]
00007FFADA6D514E E87D62AE5F           call    CORINFO_HELP_THROW
LBL_0:
00007FFADA6D5153 488B5510             mov     rdx,[rbp+10h]

[jkotas]

Note that this pattern is not a clear win today: #47353 (comment)

I think it would make sense to introduce this method to support the planned null checking auto-generated by the compiler. cc @jaredpar @stephentoub

[geeknoid]

There are a couple things relative to #47353:

• That PR talks about the impact to the IL size. I think for most uses, IL size doesn't matter to the runtime of the code. I am much more concerned by the size of the native code produced by the JIT. This has a real RAM cost, and impacts execution performance in a measurable way. But I believe my proposal here would also result in smaller IL overall.

• That PR references the idea of auto-generated ModuleThrowHelpers, whereas I'm proposing to add those static methods directly into the exception types. That makes them shared between all assemblies in a process, so the gains will be substantial overall, both in total IL size and in native code size. Additionally, the pattern I propose here is considerably more discoverable. And heck, it's ever fewer characters to type in the source as well :-)

[jkotas]

more concerned by the size of the native code produced by the JIT. This has a real RAM cost

I agree. Switching inline throw new ArgumentNullException to use this API everywhere would likely increase the RAM cost due to optimizations for the inline throw pattern in the JIT (you have to count the code size and also size of the supporting datastructures). It can be fixed with some work in the JIT.

In other words, this API sounds like a good idea, but turning it into actual RAM win likely requires work in the JIT to make it as efficient as the inline throw pattern.

[jkotas]

@EgorBo Interested in looking into this?

[EgorBo]

@jkotas it's not clear to me what is missing from the JIT side
These new Throw-helpers will be imported as cold-blocks. Are you referring to the LazyStringHelper optimization?
It can be enabled for all cold blocks: https://github.com/dotnet/runtime/blob/master/src/coreclr/jit/morph.cpp#L9472

[sharwell]

@jkotas It might not be a big win from generated code or IL size in applications, but it's a very big win for localization of common validation scenarios. Localization of ThrowHelper is the largest impediment to distributing Microsoft.CodeAnalysis.Collections today.

[stephentoub]

Localization of ThrowHelper is the largest impediment to distributing Microsoft.CodeAnalysis.Collections today.

I don't understand. What in ThrowHelper itself needs to be localized, and how does that impact whether code uses a ThrowHelper-like pattern or not?

[sharwell]

If ThrowHelper was a public API, we could use it directly and not need to include localized messages in Microsoft.CodeAnalysis.Collections. Since ThrowHelper isn't public, we had to port it over as part of the collections library and handle provide all the localized resources. Since the package is distributed as a source package, we have to distribute these resources as part of the source package, and it's difficult to incorporate those localized resources as part of downstream builds.

The point of this is less that we need ThrowHelper to be a public API, but rather the value we would gain from having ThrowHelper be a public API isn't derived from the specific points being considered previously (IL gains, perf, etc.).

[stephentoub]

That's very different from what's being proposed here. You're actually asking for public APIs for resources Corelib uses?

[sharwell]

@stephentoub looks like I got mixed up between the two proposals when following links and seeing comments like #47353 (comment)