Feedback: boxed unions type test in type unions

[hez2010]

I'm opening this discussion to provide some feedback on the TypeUnions proposal.

In

csharplang/proposals/TypeUnions.md

Line 336 in dcea688

However, when neither type in the test is statically known to be related to a union struct, the type test will fail.

we have

bool IsType<T>(object value) => value is T;

U u = new A(...);
// always fails
if (IsType<A>(u)) {...}

This is because the language will not special case the type test when no union struct members are involved, since its not clear which type to check for. Checks for a common union interface could be made to work, but that would unduly impact the vast majority of type tests that do not involve union structs.

Today we are specializing code for value-type type parameters, so that IsType<A> will be specialized to its own code anyway.

Given this fact, here we can ask the JIT for some help: we can change the JIT to generate additional code for testing type against the union, only for specialized code whose type arguments are union structs.

Do note that this doesn't mean we are relying on the JIT impl details to implement the type testing. In general, we need to support union structs for all cases involving type testing, here what I'm talking about is an optimization that JIT can be smart so that it won't regress cases that are not involving union structs.

Preparation

We use a marker interface for all type unions and the C# compiler always emit code that do the type test against the marker interface.
Besides, the C# compiler emits an attribute [TypeUnionCase(typeof(<containing union struct>))] for union struct cases. Also it emits a generic version of TryGet<T> for use by the VM or the JIT.

Say now we have

union struct U
{
    A();
}

It got lowered to

struct U : ITypeUnion
{
    public bool TryGet<T>(out T value) {...};
}

[TypeUnionCase(typeof(U))]
struct A : ITypeUnion
{
    public bool TryGet<T>(out T value) {...};
}

interface ITypeUnion
{
    bool TryGet<T>(out T value);
}

By the way, by adopting the marker interface, existing libraries like OneOf and etc. can also implement ITypeUnion so that they can get the language support for free.

Option 1: Implementation in VM, Optimization in JIT

Just like what we are going to do for ref struct in type arguments, we use the same intrinsic methods bool RuntimeHelpers.IsInstanceOf<TFrom, TTo>(TFrom source) and TTo RuntimeHelpers.CastTo<TFrom, TTo>(TFrom source) for type testing and type casting.

For type testing, the C# compiler always emit:

bool IsType<T>(object value)
{
    return RuntimeHelpers.IsInstanceOf<object, T>(value);
}

The implementation will be handled by IsInstanceOf, and will be optimzied by the JIT, while Roslyn doesn't need to do anything else.

Then the two intrinsic methods will be updated to support boxed struct unions, and because the JIT can see the exact type argument in value type cases, they can be specialized and expanded during compile time so that

1. If TTo is a case member of a type union, it will be imported as source is U u && u.TryGet<TTo>(out _);
2. Otherwise, there's nothing need to do

This can make sure we always get the correct result on any VM: for VMs that don't recognize the intrinsics, we pay for some overhead to run the fallback implementation in IsInstanceOf and CastTo; for others, there will be no performance penalty at all.

Option 2: Optimization in JIT

For type testing, the C# compiler always emit:

bool IsType<T>(object value)
{
    return value is ITypeUnion u ? u.TryGet<T>(out _) : value is T;
}

When the JIT generates code for a method Foo<A>, it looks for TypeUnionCaseAttribute on the type argument A when A is a value type. If the attribute is found, in the importer stage, the JIT fetches the union type U from the attribute and inserts additional code to do type test against the union so that the code

bool IsType<T>(object value)
{
    return value is ITypeUnion u ? u.TryGet<T>(out _) : value is T;
}

becomes

// specialized code for value type `A`
bool IsType<A>(object value)
{
    return value is U u && u.TryGet<A>(out _);
}

while for others like Foo<B> where B is a non-union struct or a class, the codegen won't be changed so the performance of type test against non-union types won't be regressed.

// specialized code for value type `B`, where `B` is not a union struct
bool IsType<B>(object value)
{
    return value is T;
}

// shared code for reference type
bool IsType<__Canon>(object value)
{
    return value is T;
}

Note

We may also consider to update the implementation of Type.IsSubclassOf to support this for System.Type. Type.IsSubclassOf is a JIT intrinsic so we can do this smart without regressing performance for most cases while providing fallback code for runtime that doesn't support this intrinsic. And the IL sequence box - isinst may also need to be updated, just like what we did for ref struct, so that the behavior can be consistent.

Conclusion

In this way we can support type testing and casting for boxed union struct, also we don't regress the performance for cases other than union struct.

[timcassell]

I think people will be very confused to find that it works for struct unions but not class unions.

Also, will that work for AOT shared generics?

[hez2010]

1. union class is based on inheritance hierarchy where type testing already works out-of-box.
2. there's no difference between JIT and AOT for value-type specialization, it works for both JIT and AOT

[timcassell]

1. union class is based on inheritance hierarchy where type testing already works out-of-box.

Ah, makes sense.

2. there's no difference between JIT and AOT for value-type specialization, it works for both JIT and AOT

And what about cases where the specialization cannot be generated per type due to reflection MakeGenericMethod? AOT still has to create shared generics for those even if they are value types.

[HaloFour]

And what about cases where the specialization cannot be generated per type due to reflection MakeGenericMethod? AOT still has to create shared generics for those even if they are value types.

My understanding is that this is not possible with AOT with statically unknown types. As for JIT, I don't see why it wouldn't specialize that like it normally would. Otherwise it would have to box.

[timcassell]

My understanding is that this is not possible with AOT with statically unknown types.

It absolutely is possible, and is done by Unity's IL2CPP. https://unity.com/blog/engine-platform/il2cpp-full-generic-sharing-in-unity-2022-1-beta https://discussions.unity.com/t/unity-future-net-development-status/836646/1094 Though I have no idea if NativeAOT etc use the same code-gen strategy.

[hez2010]

AOT still has to create shared generics for those even if they are value types.

Then they need to handle things in the shared code.
As for NativeAOT, this is not a thing and every value type will be specialized.
MakeGenericType simply doesn't work for value types that don't have specialized code generated in NativeAOT.

[IS4Code]

I have proposed a general solution to this and a broader range of situations in the runtime repo (dotnet/runtime#105923), but I'd definitely appreciate seeing this addressed!

[timcassell]

I don't think that actually solves this case since we're dealing with 2 struct types. It needs to be unboxed to U then unwrapped to A. Users could type check for either or both types, and a custom boxing implementation by itself can't handle that.

[IS4Code]

@timcassell I think it could, depending on the implementation. If value is T is equivalent to checking that (T)value is valid, the runtime should be able to verify that an [IndirectlyBoxable] T can be boxed to the type of one of its active fields, and thus such a type must satisfy is T.

The attributes (for option A in the proposal) basically give off the same information as [TypeUnionCase] here.

[jkoritzinsky]

I think if there's going to be any runtime support for these sorts of type tests, it should be in the VM in the casting support. It could still use the same sort of annotations (attribute on the case type pointing back to the union type), but it should be implemented at the same layer of our other "special casting case" support, like IDynamicInterfaceCastable and built-in COM interop.

For the purposes of the language, it doesn't really matter who implements the special casting rules, just that they're runtime implemented and that the C# compiler and spec can specify that an unboxing cast would lower to a regular cast instruction.

This ends up being a special case of @IS4Code's proposal I guess (though marginally less footguns and slightly simpler implementation because it's a more constrained scenario).

As a further optimization, the JIT could optimize these casts, but it should start as a VM feature if there's any runtime support at all.

[hez2010]

Aggreed. I have updated the original post to reflect this.

[CyrusNajmabadi]

We also need to update the implementation of Type.IsSubclassOf

I'm not sure I agree that this is needed. I would change this more to: we could also consider...

Instead

[hez2010]

Updated.