noexcept or NoExceptionAttribute for async methods

[hez2010]

Background

In the current version of C#, an async method will yield a state machine with try-catch blocks in the MoveNext method. But this would prevent the JIT optimizing (especially, inlining) the MoveNext, which will greatly harm the performance of async methods.

Proposal

Introduce a keyword noexcept or an attribute NoExceptionAttribute for async methods, then compiler won't generate try-catch blocks for methods annotated with noexcept or [NoException].

This could also be extended to other scenarios to suppress compilers emitting try-catch in auto-generated code.

Usage

noexcept async Task<int>(int x)
{
    await Bar();
    return x;
}

or

[NoException]
async Task<int>(int x)
{
    await Bar();
    return x;
}

and the compiler will lower it to

[CompilerGenerated]
struct FooAsyncStateMachine
{
    ...
    public void MoveNext()
    {
        // no try-catch blocks emitted
    }
}

This is especially useful for ValueTask<T> scenarios:

Console.WriteLine(await Foo());

noexcept ValueTask<int> Foo()
{
    return ValueTask.FromResult(1);
}

Now we will have the potential to inline the async method call.

[jnm2]

What happens when an exception is thrown then?

[jnm2]

noexcept is guaranteed by users, so in this case the exception will be omitted away, which is the same behavior with async void.

So then you are still emitting try/catch? If not, then the exception bubbles up, just not to a sensible place.

[hez2010]

noexcept is guaranteed by users, so in this case the exception will be omitted away, which is the same behavior with async void.

So then you are still emitting try/catch? If not, then the exception bubbles up, just not to a sensible place.

My bad. It's not the same with async void, instead it throws an unhandled exception.

[HaloFour]

You can do this today by removing the async modifier from the method.

[jnm2]

@hez2010 I don't think this is safe in any way. The exception bubbles up to a place that is hard to reason about. It might forcibly terminate the application (if it's a bare thread) or get picked up in a message loop exception handler or thread pool exception handler.

[jnm2]

For all I know, it might leave a state machine somewhere in the async call stack in an invalid state from which the application tries to recover with bad results.

[alexrp]

noexcept would imply no allocations. What async code can actually function with zero allocations under any circumstances?

[huoyaoyuan]

Are OOM/SO treated as unrecoverable?

[TahirAhmadov]

To my knowledge, the exception wouldn't even be swallowed - it would bubble up that worker thread's call stack and crash your application.
Also, I'm not convinced MoveNext being inlined is prevented by the try-catch; if I'm not mistaken, they use the generic constraint interface trick to avoid boxing the state machine, and MoveNext becomes essentially an Opcodes.Call, and it's easy to inline it already.
Don't quote me on the points above, but I'm >70% I'm correct on both.

[hez2010]

being inlined is prevented by the try-catch

The JIT will refuse to inline any method contains try-catch blocks.

[Neme12]

I don't think you can really guarantee that exceptions won't be thrown in any meaningful piece of code. The runtime can throw exceptions almost everywhere.

[theunrepentantgeek]

In the current version of C#, an async method will yield a state machine with try-catch blocks in the MoveNext method. But this would prevent the JIT optimizing (especially, inlining) the MoveNext

This is less an argument that the C# language needs to change and more one that there's room for improvement in the JIT compiler - if it could be enhanced to inline methods as you suggest, the benefit would apply across a far wider range of methods and runtimes than a narrowly scoped niche language change.

which will greatly harm the performance of async methods.

Have you benchmarked the overhead of the async state machine?

I haven't done so myself, but my intuition is that the overhead would be on the close order of 10s or 100s of nanoseconds, which pales into insignificance against the thread scheduling overhead of the OS (usually milliseconds) or round-trip networking (typically milliseconds, but sometimes microseconds in specialist cases).