Proposal: RuntimeHelpers.GetRawData

[MichalStrehovsky]

Proposal

I suggest we add the following method to System.Runtime.CompilerServices.RuntimeHelpers:

namespace System.Runtime.CompilerServices
{
    public static class RuntimeHelpers
    {
        public static ref byte GetRawData(object o);
    }
}

Given an object instance o, this would return a managed reference to the first field of the type (or first element of an array if o is an array, or first character of a string if o is string). This can be implemented the same way JitHelpers.GetPinningHelper is implemented within the CLR and would have similar use.

Alternatives considered

We could place the helper in System.Runtime.CompilerServices.Unsafe, but that would be troublesome for variable-length types (arrays and string). If we ever add new ones (such as the Utf8string prototype), the API might not do what the user expects. This API needs to be versioned with the underlying runtime.

Example Usage

Create a strongly typed reflection-free field getter and setter:

abstract class FastFieldAccessor
{
    public abstract object GetValue(object o);
    public abstract void SetValue(object o);
}

class FastFieldAccessor<T> : FastFieldAccessor
{
    private IntPtr _offset;

    public FastFieldAccessor(object o, ref T field)
    {
        _offset = Unsafe.ByteOffset(ref RuntimeHelpers.GetRawData(o), ref Unsafe.As<T, byte>(ref field));
    }

    public override object GetValue(object o)
    {
        return Unsafe.As<byte, T>(ref Unsafe.Add(ref RuntimeHelpers.GetRawData(o), _offset));
    }

    public override void SetValue(object o)
    {
        Unsafe.As<byte, T>(ref Unsafe.Add(ref RuntimeHelpers.GetRawData(o), _offset)) = (T)o;
    }
}

[xoofx]

Would love to have this actually. Typically, the fact that we don't have access today to JitHelpers.GetRawSzArrayData(this Array array) is annoying because there are many optimizations that CoreCLR can do internally on arrays that we can't do on our own.....

@MichalStrehovsky, what would be the story to calculate the offset field? I'm not a fan of the convoluted code we have to go through today like this:

    class MyClass
    {
        public string field;
        public int field2;
    }

    class MyClassOffset
    {
        private static readonly MyClass Temp = new MyClass(); 
        public static readonly int OffsetField2 = Unsafe.ByteOffset(ref Unsafe.As<string, int>(ref Temp.field), ref Temp.field2).ToInt32();
    }

Wondering if as part of the CLR change required for interface static methods, if we should not introduce more IL opcodes for these kind of scenarios... 🤔

[xoofx]

Wondering if as part of the CLR change required for interface static methods, if we should not introduce more IL opcodes for these kind of scenarios...

Thinking more seriously about this, I'm worried that we could miss an opportunity here (we don't have the occasion to have breaking changes to the IL), so should we think more broadly about what would be relevant to bring to these CLR changes? @jkotas what do you think?

[jkotas]

I think that GetRawData(object o) is too low-level as public API with unclear semantics around arrays, etc. I would be ok with ref char GetRawData(string s) or ref T GetRawData<T>(T[] s).

The fast field accessors that are shown in example usage should be first class public APIs exposed by the runtime. I believe we have some related issues about this. I do not think we want everybody to be implementing their own version of them from low-level building blocks. We want them to be owned by the runtime so that we can optimize the heck out of them, without compromising type safety.

breaking changes to the IL

I do not think this proposal requires any changes to the IL. Also, note that interface static methods are not a breaking change. It would be a breaking change if existing programs stopped working which is not the case. The fact that new features require new runtimes is not a breaking change.

[xoofx]

I do not think this proposal requires any changes to the IL.

Yeah, I was not asking about this issue in particular. For example, calculating the offset of a field from a root object is "quite common" for low level access so a fld.offset opcode would be actually useful, while today we have to go through lots of convoluted unsafe API to get something like this....

[jkotas]

For example, calculating the offset of a field from a root object is quite common

What are the scenarios you need the offsets for? I would rather look at what you are trying to do and see what is the best way to address it. Offsets are way too low-level.

[xoofx]

What are the scenarios you need the offsets for?

For example: an animation engine, instead of having full codegen for accessing fields of structured data (which incurs an indirect call and hurts instruction cache in the end with too many of them) you can use instead field offsets to manipulate the data efficiently. Today, we need to use the code I showed above to calculate the offset, which incurs to allocate a temporary object to calculate this offset and calling multiple methods from Unsafe, while this offset is accessible from the JIT/AOT compiler relatively easily. In C# this could translate to something like offsetof(MyStruct.field2) with a direct opcode for it...

[jkotas]

an animation engine, instead of having full codegen for accessing fields of structured data

Would the type safe field accessors work for this? I would like to have a type safe default that would be used in most cases, and have unsafe escape hatch for cases where the type safety check is too expensive.

[xoofx]

Would the type safe field accessors work for this?

Not sure I know this, do you have an example how does it work?

[jkotas]

E.g. We can introduce a fully type safe field accessor like this:

struct FieldAccessor<TType, TField> where TType : class
{
    int _offset;

    public ref TField GetValue(TType obj)
    {
        return ref *(obj + _offset); // pseudo code 
    }
}

[xoofx]

E.g. We can introduce a fully type safe field accessor like this:

Oh right, this is what I would use in the end once I have the offset.

My concern is more for the calculation of _offset. Today, we don't have an IL instruction for calculating it. We have to go through something like Unsafe.ByteOffset(ref Unsafe.As<string, int>(ref Temp.field), ref Temp.field2).ToInt32(); (and create a temp instance of MyStruct for example) while I'm looking for something like offsetof(MyStruct.field2)

[jkotas]

There would be a factory method to get the FieldAccessor from the FieldInfo or RuntimeFieldHandle. The factory would be a slower method - it would validate the types.

[xoofx]

There would be a factory method to get the FieldAccessor from the FieldInfo or RuntimeFieldHandle. The factory would be a slower method - it would validate the types.

As long as we can avoid using reflection (and allocating lots of managed memory) to fetch this token, I'm fine with this approach. I assume that we would have proper support in Roslyn to do a ldtoken via something like handleof(xxx) as described in the intrinsics support proposal?

[jkotas]

Right.

[MichalStrehovsky]

I assume that we would have proper support in Roslyn to do a ldtoken

And for a cross-cutting feature like this, we can look forward to having it available in .NET Core 5 or 6 :).

I'm proposing to expose a low level building block like this to address the needs people have right now. It's similar to the function pointer support that C# is adding - they could have waited for static delegates, but they want to address problems people are having now, as opposed to selling them on how great things will be 3 years from now.

ML.net is using Reflection.Emit because of what appears to be a lack of building blocks: dotnet/machinelearning#1736

[xoofx]

And for a cross-cutting feature like this, we can look forward to having it available in .NET Core 5 or 6 :).

But I thought that handleof is so simple (and similar to nameof) that it should not be much trouble to bring this to Roslyn. What is the alternative if we don't have support baked into Roslyn? (considering Reflection.Emit is a no go)