How can I get a field offset from a Class for managed ref?

[cyraid]

Hi there,

Do field offsets get moved around? I noticed there was a NotImplemented.ByDesign if I recall poking around the source. Since there's no guarantee the internal metadata for a Class will stay the same, how would I get the field offset myself? (by just having access to typeof(ClassName))

Edit: Also note that the class is unstructured, so no [FieldOffset] and such (so I can't use Marshal.OffsetOf)

[cihatsolak]

Hi, field offsets can change, so you shouldn't rely on them being fixed. If you absolutely need to access the field of an unmanaged reference and the class is unconfigured (i.e. no [FieldOffset] attribute), you can use the System.Runtime.CompilerServices.Unsafe class to get the field offset at runtime. The Unsafe.OffsetOf method returns an IntPtr that represents the byte offset of the specified field in the type, which can be converted to a long value using the ToInt64 method.

[Clockwork-Muse]

Perhaps the better question is, why do you want this information? What are you planning on doing with it?

[cihatsolak]

Perhaps the better question is, why do you want this information? What are you planning on doing with it?

thank you for this good question

[cyraid]

Yup, good question.

Currently developing a virtual runtime that executes instructions (there are requirements to why I can't actually emit IL or bytecode, or use reflection), and it has to be NativeAOT compatible. The runtime executes functions from a code pointer which acts like the instruction pointer for a CPU. Having a delegate is too slow, which is why it's nice to have C# function pointers (which is put in a different question, as I need some functionality from there too).

The runtime accesses fields from instances, which need to be really fast. Currently I bind the fields when the Object is instantiated through a nice unsafe __makeref() pointer->pointer trick, then stores the offsets and doesn't need to do that after another Object of the same type is instantiated. Though, it would be nice if I could do this upfront.

Edit: Funny story, I was actually making the VM/runtime in C/C++, and it turns out I actually optimized the C# so much that it actually runs FASTER than C/C++! (in NativeAOT mode). Even when the instructions are similar. So good job to the C# folk. So now can just focus on all the work in C#. :D

[Clockwork-Muse]

.... this sounds like you're trying to dodge around a "no dynamic code" restriction (although NativeAOT limits some of that anyways).

If you're using NativeAOT, though, I'm not sure what's going to happen things like those field offsets.,,

[cyraid]

.... this sounds like you're trying to dodge around a "no dynamic code" restriction (although NativeAOT limits some of that anyways).

If you're using NativeAOT, though, I'm not sure what's going to happen things like those field offsets.,,

Works for me quite nicely in NativeAOT mode. :) Just would like to do it not so 'hacky'. Now if only there was a way to convert delegates to managed function pointers. As for the fields go, I have it setup so a Source Generator I develop in the future can make a lot of the code I'm boiler plating currently.