Add GetReference and TryGetArray to MemoryMarshal

[ahsonkhan]

Sets up the ground work for:
https://github.com/dotnet/corefx/issues/25412
https://github.com/dotnet/corefx/issues/25615

Test updates and changes in corefx to follow after. dotnet/corefx#25789

Following the staging plan from here: https://github.com/dotnet/corefx/issues/23881#issuecomment-343767740

1. Add MemoryExtensions.GetReference/TryGetArray
2. Convert all uses of DangerousGetPinnableReference/DangerousTryGetArray in coreclr, corefx, corert, corefxlab, aspnet, ... to MemoryExtensions.GetReference
3. Change DangerousGetPinnableReference to whatever we like to make it fit the pinning pattern and remove DangerousTryGetArray.

Doing it this way will avoid the need for complex staging or things being on the floor for extensive periods of time.

cc @jkotas, @stephentoub, @KrzysztofCwalina

[jkotas]

This should return ref T. ByReference<T> should be used only for the fields.

[ahsonkhan]

Why is that?

Wouldn't this make the implementation, essentially a duplicate, but internal, version of DangerousGetPinnableReference?

i.e.

internal ref T Reference => ref _pointer.Value;

Do we then just return Reference from MemoryMarshal.GetReference()?

[jkotas]

Why is the AggresiveInlining necessary?

I know that you got into habit of marking everything with AggresiveInlining. I do not think it is a good idea to do blindly - it should be done only when you have a clear data that it helps.

[ahsonkhan]

For this instance, I wanted to remain consistent with DangerousGetPinnableReference which already had it, presumable for good reason. I will try to run some experiments.

[jkotas]

ok

[ahsonkhan]

Inlining in almost all cases made no difference.

The only case inlining helps is if the implementation is using in and the Reference property.

[jkotas]

Have you tried whether it is worth it to have in here? (It was discussed in the issue.)

[ahsonkhan]

Using in doesn't really help (at least for fast span). And if we don't inline the method, it actually hurts performance.

If I pass a Span using in, it seems to hurt performance in some cases:

[MethodImpl(MethodImplOptions.NoInlining)]
public static void CallTestMethodWithIn(Span<int> span)
{
    int temp = TestMethodWithIn(span);
}

[MethodImpl(MethodImplOptions.NoInlining)]
public static void CallTestMethodWithoutIn(Span<int> span)
{
    int temp = TestMethodWithoutIn(span);
}

[MethodImpl(MethodImplOptions.NoInlining)]
public static int TestMethodWithIn(in ReadOnlySpan<int> span)
{
    int val = 0;
    for(int i = 0; i < span.Length; i++)
        val ^= span[i];
    return val;
}

[MethodImpl(MethodImplOptions.NoInlining)]
public static int TestMethodWithoutIn(ReadOnlySpan<int> span)
{
    int val = 0;
    for (int i = 0; i < span.Length; i++)
        val ^= span[i];
    return val;
}

Runtime (s):
CallTestMethodWithoutIn: 6.3821768
CallTestMethodWithIn: 6.8055258

There is an extra compare and jump in the loop body if I pass the Span with in.

[jkotas]

I do not think the Reference property will get inlined here for the class case. We may want to make the field internal instead.

[ahsonkhan]

The ByReference<T> _pointer field?

[jkotas]

Yes.

[ahsonkhan]

Yes, it looks like without AggressiveInlining it doesn't get inlined.

[jkotas]

Can this be just return (((OwnedMemory<T>)obj).TryGetArray(out var arraySegment) ?

[jkotas]

I see - you need to add the local index.

[ahsonkhan]

I tried to toggle the implementation based on these 3 factors:

• AggressiveInlining
• Use of in
• Use Reference property or _pointer field

Most of these had negligible impact. The only one that made a difference was AggressiveInlining only if I passed the Span using in.

Given that these factors don't really affect the results (and using in requires AggressiveInlining), I will use this implementation:

GetReference(Span<T> span) => ref span._pointer.Value;