Is add operation on object reference valid?

[buybackoff]

ECMA 335 says in one place in parentheses that addition is supported for O types.

Other places say that's it's not OK.

We have a discussion on the fastest and still correct way to read array elements without bound checks here: disruptor-net/Disruptor-net#65

In the following implementation, is it OK to use the result of ldind.ref as a managed pointer and add offset to it? Is the result a GC-tracked managed pointer?

  .method public hidebysig static !!0/*T*/&
    UnsafeGetAt<T>(
      !!0/*T*/[] 'array',
      int32 index
    ) cil managed
  {
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor()
      = (01 00 00 00 )
    .param type [1] /*T*/
      .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor([in] unsigned int8)
        = (01 00 02 00 00 ) // .....
        // unsigned int8(2) // 0x02
    .maxstack 3

    IL_0000: ldarga.s     'array'
    IL_0002: ldind.ref    // Put O on the stack
    IL_0003: ldarg.1      // index
    IL_0004: conv.u      // zero-extend
    IL_0005: sizeof       !!0/*T*/
    IL_000b: mul
    IL_000c: call         int32 ArrayUtil::get_ArrayDataOffset()
    IL_0011: add
    IL_0012: add        // O + offset: the result is tracked & or nint with a GC hole?
    IL_0013: ret           

  } // end of method ArrayUtil::UnsafeGetAt

Asking specifically for #if NETCOREAPP, on Mono it blows up (and on net48 it works but it's not that important so could take safe slower path as with Mono and use simple if-def).

[huoyaoyuan]

Sounds like what Unsafe.Add is doing.

[buybackoff]

@huoyaoyuan The first argument of Unsafe.Add is a managed pointer, not an object reference.

[huoyaoyuan]

I'm not familiar with precise definition of IL concepts, but AFAIK Unsafe.Add is used for span element indexing to bypass bound check.

[ltrzesniewski]

Span<T> already has something equivalent to a managed pointer (a ByReference<T> field, which the runtime treats just like a byref field). This is a & type in IL terms, and it allows arithmetic (see the table above).

We want to start with an object reference (O type in IL terms) and perform arithmetic on it, which ECMA-335 disallows. The standard also makes it quite clear that the O and & types are not interchangeable.

The question essentially boils down to: "how to convert an O type to a & type in a supported way?".

[Joe4evr]

The question essentially boils down to: "how to convert an O type to a & type in a supported way?".

Wait for byref field support to be official?

[ltrzesniewski]

Wait for byref field support to be official?

The question is unrelated to fields. It asks about item types on the IL evaluation stack.

[SingleAccretion]

ECMA 335 says in one place in parentheses that addition is supported for O types.

@buybackoff It is not supported, this seems like a mistake in the standard (though you'll note this is "informative text").

E. g. if I ran the following through RyuJit built with assertions, it'll fail:

[MethodImpl(MethodImplOptions.NoInlining)]
private static ref int Problem(ClassWithFields a)
{
    IL.Emit.Ldarg(0);
    IL.Emit.Ldc_I4(4);
    IL.Emit.Conv_I();
    IL.Emit.Add();

    return ref IL.ReturnRef<int>();
}

Assert failure(PID 10764 [0x00002a0c], Thread: 19252 [0x4b34]): Assertion failed 'genActualType(op1->TypeGet()) != TYP_REF && genActualType(op2->TypeGet()) != TYP_REF : Possibly bad IL with CEE_add at offset 0003h (op1=ref op2=long stkDepth=0)' in 'RyuJitReproduction.Program:Problem(ClassWithFields):byref' during 'Importation' (IL size 5)

Relying on illegal IL being accepted is undefined behavior and is not supported.

[SingleAccretion]

.NET itself does this with RawArrayData https://source.dot.net/#System.Private.CoreLib/src/System/Array.CoreCLR.cs,42e9b7616956cf94

Yes, and it has UB issues. See #58312 (comment).

[buybackoff]

@SingleAccretion UB in terms of specs or .NET 6 implementation? My original question was if in .NET 6 O + nint is nint or & in the current implementation, I could understand that the first picture from specs is a typo.

This is another use of a different type, which is the most relevant to this discussion https://source.dot.net/#System.Private.CoreLib/src/System/Runtime/InteropServices/MemoryMarshal.CoreCLR.cs,0a97cbc893e44c76,references

[SingleAccretion]

UB in terms of specs or .NET 6 implementation?

Both.

[SingleAccretion]

My original question was if in .NET 6 O + nint is nint or & in the current implementation

I understand what you're getting at -- and I can only tell you that internally the compiler treats O + nint as &. However, as the assertion showed above tells - it is unknown and untested how will the compiler behave if such constructs appear in user code (IL). It may behave sensibly and reliably, it may crash, it may silently produce bad (in subtle ways) code.

[buybackoff]

I have 700 unit tests all depending on that, everything works well. But on a quiet machine without much GC (but tests are running in parallel). Maybe I should leave overnight "run until failure", but with your comment this will not give anything. I really hoped that in the current implementation there is no difference between O and &.

For GC it looks safe from this comment: dotnet/coreclr#20386 (comment)