Reference-or-nuint runtime type

[bencyoung-Fignum]

Thinking about the new union feature and how it could be optimized in the future. I think all (not saying it's easy) that is probably needed is a built in struct type RefOrNuint or similar that has a pointer and some sort of byte sized tag. It would have to be known to the GC during compilation so that the GC knows if the tag is e.g 0 in which case the data payload is treated as a reference, else it is treated as raw data. You'd need methods to TryGetReference(out object? value) and TryGetData(out nunit? data) and equivalent to set

As a stretch you could expose the tag you'd need too to be able to make the nunit data is exposing other types but it wouldn't be built in. E.g. TryGetData(out byte? tag, out nunit? data). The tag would always be 0 for references and trying to set it to 0 for a non reference would throw

The internal code would have a special write barrier that depends on the tag value, and the GC would also check the tag before enumerating the value as a root

Once you had this primitive then all kinds of compressed types, unions, short vectors etc become possible, but from a runtime perspective all the attention could be focused on this?

[huoyaoyuan]

This will introduce significant overhead for very little benefit, if not zero.

some sort of byte sized tag

This is really an impossible thing. Since every GC reference requires strict pointer alignment, the tag will likely take up a whole pointer. Then you would have a pointer of RefOrNuint and a pointer of tag, saving zero space but introduces much more complexity. Trying to compact multiple tags into one pointer will only make things unmanagable.

[bencyoung-Fignum]

It's ok, the pointer can be first, leading to a 72 bit object rather than aligning the pointer as a second object :)

[tannergooding]

Such unions are typically extremely inefficient and hurt aliasing, optimizations, and many other considerations. They are not actually all that good to have, use, or provide.

I am personally a bit doubtful we'd add such support, particularly given the push towards memory safety and reducing unnecessary unsafe code.

[toupswork]

@tannergooding - just curious, on the topic of reduction of unsafe code, is that just for exposing public unsafe APIs due to the changes coming in the next C#, or as a runtime engineer, is the goal also to reduce unsafe code for internal APIs?
What I am curious about is how that affects runtime engineers like yourself from being able to write performant code for libraries when the RyuJit, as advanced as it is, still has significant limitations in determining via inter procedural analysis if optimization can be made. I think much of that is due to C# -> IL not providing information density that that JIT can use to disambiguate between optimization qualification and disqualification.