Description
PR dotnet/coreclr#26310 added in an experimental feature, guarded by an environment variable feature flag, that uses cached objects behind the scenes to implement async ValueTask
and async ValueTask<T>
methods. For .NET 5, we need to decide how to proceed with this feature:
- Delete it
- Keep it as opt-in
- Keep it as opt-out
- Always on (delete the fallback)
We need more data to decide how to proceed, and in particular:
- Are there workloads where it yields a significant performance benefit when it's enabled?
- Are there workloads where it measurably harms performance when it's enabled?
- What kind of impact does it have on code size in a representative app?
- What is a good strategy to use for the employed cache?
If we decide to keep it, and especially if we decide to keep it as opt-out or always-on, we also need to validate diagnostics, in particular tracing to ensure we're not regressing anything impactful.
Functionally, there's also a behavior change associated with it. While ValueTask
/ValueTask<T>
are documented to only be used in very specific ways, the fact that instances produced by async
methods before .NET 5 were backed by Task
meant that you could get away with violating the contract. This change generally ends up requiring that the contract be enforced. We would want to ensure we had good analyzers in place to help catch any misuse: https://github.com/dotnet/corefx/issues/40739.
CALL TO ACTION:
Please try out the bits with your app and share your results: throughput, memory load, etc.
To enable the feature, set the DOTNET_SYSTEM_THREADING_POOLASYNCVALUETASKS
environment variable to either 1
or true
.
This will only impact async ValueTask
and async ValueTask<T>
methods, so you may also want to look through your code to switch some internal and private async Task
/async Task<T>
methods to instead use ValueTask
/ValueTask<T>
... just make sure to only do so when the consumers abide by the rules, which is that an instance must only be consumed once: if callers are doing anything other than directly awaiting the result of the method, be careful.