Span<T>

[jkotas]

Turn https://github.com/dotnet/corefxlab/tree/master/src/System.Slices into efficient first class feature.

• Initial implementation: Merge SpanOfT branch into master coreclr#7886
• Design document: https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md
• JIT - Correctness – proper GC reporting of the special byref field
  • Re-enable GC layout reporting for Span https://github.com/dotnet/coreclr/blob/f42984160f5f9407f70ebc2e86edfcf226fccd81/src/vm/jitinterface.cpp#L2306. JIT chokes on it - fragile assumption introduced by recent JIT throughput fix.
  • Intrinsic for reading/writing byrefs https://github.com/dotnet/coreclr/blob/f42984160f5f9407f70ebc2e86edfcf226fccd81/src/mscorlib/src/System/Span.cs#L39, multiple places
• VM - Correctness
  • proper GC reporting: https://github.com/dotnet/coreclr/issues/8517
  • enforcement of byreflike constrains https://github.com/dotnet/coreclr/issues/8516
  • https://github.com/dotnet/coreclr/issues/9032
• VM - Stress
  • GC reporting for tailcalls - https://github.com/dotnet/coreclr/issues/9032
  • GC reporting for struct passed in regs on Unix - https://github.com/dotnet/coreclr/issues/9033
• JIT - Optimizations – apply same sort of optimizations to Span as it does for Strings or Arrays (treat indexers as intrinsics, range check elimination, etc.)
  • Span methods may not inline when called from shared methods dotnet/coreclr#10031
  • Improve aliasing model for implicit-by-ref struct passing dotnet/coreclr#10049
  • Recognize/optimize Span bounds checks more like array bounds checks dotnet/coreclr#10050
  • Better optimization for CORINFO_HELP_RUNTIMEHANDLE_METHOD dotnet/coreclr#10051 [moved to future]
• Update buildtools with Roslyn that has local byref and locals C# 7 feature
• Implement the full public surface dotnet/coreclr#5857
• Add Span<T> to framework contracts
• Add Span<T> tests
• Add Span<T> and ReadOnlySpan<T> as yet another ByRef-like type in Roslyn, so that unsupported operations on Span<T> like boxing or creating Span<T>[] are compile errors: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/span-safety.md
• Make sure there is a way to pin Span<T> for interop
• Debugging https://github.com/dotnet/coreclr/issues/8518 / https://github.com/dotnet/corefx/issues/14376
• Reflection - https://github.com/dotnet/coreclr/issues/17296
• Performance optimizations
  • Optimize Copy, Clear, Fill - https://github.com/dotnet/coreclr/issues/9161
• Marshaler support (as with arrays) https://github.com/dotnet/coreclr/issues/14460
• APIs across corefx that accept spans (https://github.com/dotnet/corefx/issues/21281)
• APIs for working with specialty spans (https://github.com/dotnet/corefx/issues/21395)

[stephentoub]

• Marshaler support (as with arrays)?

[adamsitnik]

I just love it, hope for some up-for-grabs issues!

[benaadams]

Does "Add Span to framework contracts" include items like adding to Stream Read/Write etc? Or is it making Span available as a type? (Assuming latter, and others will be new issues after)

[omariom]

The CoreFxLab's prototype has useful extensions methods for Span<byte> and Span<char> like Read/Write and StartsWith/EndsWith. Will CoreCLR's Span get them?

[dotnetchris]

Would there be any sane method to allow Span<> to integrate with List<> that it could operate on the underlying array?

[KrzysztofCwalina]

@omariom, we need the corfxlab API and the corlcr one to be the same (portable). The reason for it is that I think we need to use the corfxlab implementation for previously shipped runtime/frameworks, e.g. .NET Framework 4.5. Otherwise, the addoption of Span will be very much inhibited by inability to write portable code. Of course, the out-of-band span will be slower, but as long as the API is available in portable code, we should be good.

[KrzysztofCwalina]

@benaadams, we need some existing APIs, e.g. Stream.Read/Write to accept spans, but I think it's a separate workitem form the one @jkotas listed.

[KrzysztofCwalina]

@dotnetchris, what do you consider "sane" in this context? If you mean wrapping Span into List then no (Span is stack only, and does not always have "underlying array").

[KrzysztofCwalina]

@adamsitnik, I am not sure we want completely open up for grabs so early (as there is lots of tricky work here) but you have done lots of good work in corfxlab and so if you (presonally) would like to take dotnet/coreclr#5857, it would be great! Same for @omariom :-)

[adamsitnik]

@KrzysztofCwalina Thanks! consider it done ;)

[dotnetchris]

@KrzysztofCwalina i meant for Span to access List's internal array

[KrzysztofCwalina]

I think we might also need to constrain T to primitive type (i.e. type with no managed object references). Otherwise, it will be possible to create Span over native memory without GC being aware of the roots.

[omariom]

@KrzysztofCwalina
Only certain operations seem unsafe in this sense: Cast, BlockEquals and Span<byte>.Read/Write.