This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Allow MemoryPool.Shared devirtualization #33085
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Store the shared
ArrayMemoryPool
in a field of its derived sealed type so the Jit can "see" the exact type when theMemoryPool<T>.Shared
property is inlined which will allow it to devirtualize calls made on it.Is a Roslyn proposal dotnet/roslyn#30797 by @stephentoub where field initalizer, backing field and property could be combined via
{ get } =
to support devirtualization by having the auto-backing field be created as the derived type rather than the exposed type.Similar scenario to
ArrayPool<T>.Shared
dotnet/coreclr#20637@AndyAyersMS
might be a double devirt inline "opportunity" as
MemoryPool<T>.Shared.Rent
isMemoryPool<T>.Shared.Rent
=>
ArrayMemoryPool<T>.Rent
=>
new ArrayMemoryPoolBuffer
=>
ArrayPool<T>.Shared.Rent
=>
TlsOverPerCoreLockedStacksArrayPool<T>.Rent
/cc @ahsonkhan @jaredpar