Using C# 7.2 in modifier for parameters with primi

Question

C# 7.2 introduced the in modifier for passing arguments by reference with the guarantee that the recipient will not modify the parameter.

This article says:

You should never use a non-readonly struct as the in parameters because it may negatively affect performance and could lead to an obscure behavior if the struct is mutable

What does this mean for built-in primitives such as int, double?

I would like to use in to express intent in code, but not at the cost of performance losses to defensive copies.

Questions

• Is it safe to pass primitive types via in arguments and not have defensive copies made?
• Are other commonly used framework structs such as DateTime, TimeSpan, Guid, ... considered readonly by the JIT?
  • If this varies by platform, how can we find out which types are safe in a given situation?

Answer 1

A quick test shows that, currently, yes, a defensive copy is created for built-in primitive types and structs.

Compiling the following code with VS 2017 (.NET 4.5.2, C# 7.2, release build):

using System;

class MyClass
{
    public readonly struct Immutable { public readonly int I; public void SomeMethod() { } }
    public struct Mutable { public int I; public void SomeMethod() { } }

    public void Test(Immutable immutable, Mutable mutable, int i, DateTime dateTime)
    {
        InImmutable(immutable);
        InMutable(mutable);
        InInt32(i);
        InDateTime(dateTime);
    }

    void InImmutable(in Immutable x) { x.SomeMethod(); }
    void InMutable(in Mutable x) { x.SomeMethod(); }
    void InInt32(in int x) { x.ToString(); }
    void InDateTime(in DateTime x) { x.ToString(); }

    public static void Main(string[] args) { }
}

yields the following result when decompiled with ILSpy:

...
private void InImmutable([System.Runtime.CompilerServices.IsReadOnly] [In] ref MyClass.Immutable x)
{
    x.SomeMethod();
}

private void InMutable([System.Runtime.CompilerServices.IsReadOnly] [In] ref MyClass.Mutable x)
{
    MyClass.Mutable mutable = x;
    mutable.SomeMethod();
}

private void InInt32([System.Runtime.CompilerServices.IsReadOnly] [In] ref int x)
{
    int num = x;
    num.ToString();
}

private void InDateTime([System.Runtime.CompilerServices.IsReadOnly] [In] ref DateTime x)
{
    DateTime dateTime = x;
    dateTime.ToString();
}
...

(or, if you prefer IL:)

IL_0000: ldarg.1
IL_0001: ldobj [mscorlib]System.DateTime
IL_0006: stloc.0
IL_0007: ldloca.s 0
IL_0009: call instance string [mscorlib]System.DateTime::ToString()
IL_000e: pop
IL_000f: ret

Answer 2

With the current compiler, defensive copies do indeed appear to be made for both 'primitive' value types and other non-readonly structs. Specifically, they are generated similarly to how they are for readonly fields: when accessing a property or method that could potentially mutate the contents. The copies appear at each call site to a potentially mutating member, so if you invoke n such members, you'll end up making n defensive copies. As with readonly fields, you can avoid multiple copies by manually copying the original to a local.

Take a look at this suite of examples. You can view both the IL and the JIT assembly.

Is it safe to pass primitive types via in arguments and not have defensive copies made?

It depends on whether you access a method or property on the in parameter. If you do, you may see defensive copies. If not, you probably won't:

// Original:
int In(in int _) {
    _.ToString();
    _.GetHashCode();
    return _ >= 0 ? _ + 42 : _ - 42;
}

// Decompiled:
int In([In] [IsReadOnly] ref int _) {
    int num = _;
    num.ToString();    // invoke on copy
    num = _;
    num.GetHashCode(); // invoke on second copy
    if (_ < 0)
        return _ - 42; // use original in arithmetic
    return _ + 42;
}

Are other commonly used framework structs such as DateTime, TimeSpan, Guid, ... considered readonly by [the compiler]?

No, defensive copies will still be made at call sites for potentially mutating members on in parameters of these types. What's interesting, though, is that not all methods and properties are considered 'potentially mutating'. I noticed that if I called a default method implementation (e.g., ToString or GetHashCode), no defensive copies were emitted. However, as soon as I overrode those methods, the compiler created copies:

struct WithDefault {}
struct WithOverride { public override string ToString() => "RO"; }

// Original:
void In(in WithDefault d, in WithOverride o) {
    d.ToString();
    o.ToString();
}

// Decompiled:
private void In([In] [IsReadOnly] ref WithDefault d,
                [In] [IsReadOnly] ref WithOverride o) {
    d.ToString();            // invoke on original
    WithOverride withOverride = o;
    withOverride.ToString(); // invoke on copy
}

If this varies by platform, how can we find out which types are safe in a given situation?

Well, all types are 'safe'--the copies ensure that. I assume you're asking which types will avoid a defensive copy. As we've seen above, it's more complicated than "what's the type of the parameter"? There's no single copy: the copies are emitted at certain references to in parameters, e.g., where the reference is an invocation target. If no such references are present, no copies need to be made. Moreover, the decision whether to copy can depend on whether you invoke a member that is known to be safe or 'pure' vs. a member which could potentially mutate the a value type's contents.

For now, certain default methods seem to be treated as pure, and the compiler avoids making copies in those cases. If I had to guess, this is a result of preexisting behavior, and the compiler is utilizing some notion of 'read only' references that was originally developed for readonly fields. As you can see below (or in SharpLab), the behavior is similar. Note how the IL uses ldflda (load field by address) to push the invocation target onto the stack when calling WithDefault.ToString, but uses a ldfld, stloc, ldloca sequence to push a copy onto the stack when invoking WithOverride.ToString:

struct WithDefault {}
struct WithOverride { public override string ToString() => "RO"; }

static readonly WithDefault D;
static readonly WithOverride O;

// Original:
static void Test() {
    D.ToString();
    O.ToString();
}

// IL Disassembly:
.method private hidebysig static void Test () cil managed {
    .maxstack 1
    .locals init ([0] valuetype Overrides/WithOverride)

    // [WithDefault] Invoke on original by address:
    IL_0000: ldsflda valuetype Overrides/WithDefault Overrides::D
    IL_0005: constrained. Overrides/WithDefault
    IL_000b: callvirt instance string [mscorlib]System.Object::ToString()
    IL_0010: pop

    // [WithOverride] Copy original to local, invoke on copy by address:
    IL_0011: ldsfld valuetype Overrides/WithOverride Overrides::O
    IL_0016: stloc.0
    IL_0017: ldloca.s 0
    IL_0019: constrained. Overrides/WithOverride
    IL_001f: callvirt instance string [mscorlib]System.Object::ToString()
    IL_0024: pop
    IL_0025: ret
}

That said, now that read only references will presumably become more common, the 'white list' of methods that can be invoked without defensive copies may grow in the future. For now, it seems somewhat arbitrary.

Answer 3

From the jit's standpoint in alters the calling convention for a parameter so that it is always passed by-reference. So for primitive types (which are cheap to copy) and normally passed by-value, there a small extra cost on both the caller's side and the callee's side if you use in. No defensive copies are made, however.

Eg in

using System;
using System.Runtime.CompilerServices;

class X
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    static int F0(in int x) { return x + 1; }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static int F1(int x) { return x + 1; }

    public static void Main()
    {
        int x = 33;
        F0(x);
        F0(x);
        F1(x);
        F1(x);
    }
}

The code for Main is

   C744242021000000     mov      dword ptr [rsp+20H], 33
   488D4C2420           lea      rcx, bword ptr [rsp+20H]
   E8DBFBFFFF           call     X:F0(byref):int
   488D4C2420           lea      rcx, bword ptr [rsp+20H]
   E8D1FBFFFF           call     X:F0(byref):int
   8B4C2420             mov      ecx, dword ptr [rsp+20H]
   E8D0FBFFFF           call     X:F1(int):int
   8B4C2420             mov      ecx, dword ptr [rsp+20H]
   E8C7FBFFFF           call     X:F1(int):int

Note because of the in x can't be enregistered.

And the code for F0 & F1 shows the former must now read the value from the byref:

;; F0
   8B01                 mov      eax, dword ptr [rcx]
   FFC0                 inc      eax
   C3                   ret

;; F1
   8D4101               lea      eax, [rcx+1]
   C3                   ret

This extra cost can usually be undone if the jit inlines, though not always.

Answer 4

What does this mean for built-in primitives such as int, double?

Nothing, int and double and all other built-in "primitives" are immutable. You can't mutate a double, an int or a DateTime. A typical framework type that would not be a good candidate is System.Drawing.Point for instance.

To be honest, the documentation could be a little bit clearer; readonly is a confusing term in this context, it should simply say the type should be immutable.

There is no rule to know if any given type is immutable or not; only a close inspection of the API can give you an idea or, if you are lucky, the documentation might state if it is or not.