This repository was 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
ArrayMemoryPoolin a field of its derived sealed type so the Jit can "see" the exact type when theMemoryPool<T>.Sharedproperty 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>.Shareddotnet/coreclr#20637@AndyAyersMS
might be a double devirt inline "opportunity" as
MemoryPool<T>.Shared.RentisMemoryPool<T>.Shared.Rent=>
ArrayMemoryPool<T>.Rent=>
new ArrayMemoryPoolBuffer=>
ArrayPool<T>.Shared.Rent=>
TlsOverPerCoreLockedStacksArrayPool<T>.Rent/cc @ahsonkhan @jaredpar