NativeAOT type instantiation sharing

[NinoFloris]

In similar vein of #82591, would it be possible to reduce duplication when all type parameters on a type are not relevant for type layout/size?

As an example

// or struct
class Wrapper<T>
{
    public List<T> Value { get; }
}

As I understand it today this produces a new instantiation per value type for T.
I understand .NET isn't (immediately) going to support gc shapes (in the golang generics sense) as a size optimization. However this particular case seems like an analysis that can be done at the template level which can 'significantly' reduce bloat.

Is there any appetite for optimizations like these?

@MichalStrehovsky

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In similar vein of #82591, would it be possible to reduce duplication when all type parameters on a type are not relevant for type layout/size?

As an example

// or struct
class Wrapper<T>
{
    public List<T> Value { get; }
}

As I understand it today this produces a new instantiation per value type for T.
I understand .NET isn't (immediately) going to support gc shapes (in the golang generics sense) as a size optimization. However this particular case seems like an analysis that can be done at the template level which can 'significantly' reduce bloat.

Is there any appetite for optimizations like these?

@MichalStrehovsky

Author:	NinoFloris
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

People rely on this for perf optimizations. E.g. struct that implements an interface and then using that struct with a constrained generic T : IInterface method, expecting to get optimal inlining.

[NinoFloris]

I wouldn't want this to happen for methods, only for the type side. As I understand it this still adds overhead for bookkeeping that is basically entirely duplicate.

[MichalStrehovsky]

If the struct is not boxed, the type pretty much disappears after AOT compilation.

If it is boxed, the identity is observable through is checks or object.GetType. We cannot fold it - it needs a unique identity.

[NinoFloris]

The reason for this issue is the following mstat report in Slon https://github.com/NinoFloris/Slon/actions/runs/4400673130

Slon is essentially a greenfield Npgsql, which I'm using to prototype improvements that flow back into Npgsql.
To support postgres features like user defined database types and arrays, ranges etc (composition) these drivers ships with an extensible serializer. As a result we face many of the same challenges as STJ.

The interesting type that my example was modeled on is defined here https://github.com/NinoFloris/Slon/blob/main/Slon/Pg/PgConverterInfo.cs#L263-L280

This type is IMO the definition of such a data carrying type that never actually deals with T directly.

Yet here under "Top 20 Slon Types By Size" it's seen as many times as there are rooted PgConverterResolution's types closed over value type T's. I don't think we're actually boxing this particular type anywhere either.

Additionally under "Top 20 Slon Classes By Methods Size" you can find method sizes for

I'm a bit at a loss why __GetFieldHelper is as big as it is (it also grows per instantiation)

This is basically what I hope can be reduced as this brings a data organization tax where even bundling values under a nice nominal type causes bloat (as opposed to pushing them into a ValueTuple which wouldn't duplicate as PgConverter<T> is a class).

(Effectively what I'm asking for is a level of indirection such that the bulk of the instantiation data can be shared, only an nint for the shared data + nint * type arguments? stub would remain unshared to handle type identity when the type is boxed)

[MichalStrehovsky]

It indeed doesn't look like PgConverterResolution is getting boxed anywhere - the reason why there's still the extra metadata around the type is because it's a generic valuetype instantiated over reference types. Reference type instantiations do get shared but in order to know what the actual T is at runtime, an extra argument to the method needs to be provided. This extra argument is the MethodTable (which is the 112-byte thing you see).

I have a WIP change that should be able to get rid of them. I'll try to finish it tomorrow: MichalStrehovsky@530b76b

I'm a bit at a loss why __GetFieldHelper is as big as it is (it also grows per instantiation)

The method supports calling Equals/GetHashCode on the struct at runtime. There is a method body per each non-reference instantiation and the size of the individual method bodies is proportional to the number of fields on the type.

[NinoFloris]

That's fantastic @MichalStrehovsky, really cool to see the work.

So TypeDictionaries were already a thing for R2R?

Another relevant question would be whether Equals/GetHashCode should even stick around if the type is never boxed? (if it's never boxed we should be able to analyze whether Equals/GetHashCode is ever called on the T directly right?) Would the current alternative be to override these methods and leave them empty/throw?

Additionally, and I know this comes back to complicated sharing again, would it in theory be possible to analyze the body and determine T is not actually used so all instantiations could share the code?

[MichalStrehovsky]

Would the current alternative be to override these methods and leave them empty/throw?

No, that will be worse for size. The Equals/GetHashCode support is added because the compiler thinks it needs a full datastructure that describes the type. The TypeDictionary is stored in the virtual method table, along with the virtual methods. The fix I have would remove the need for both.

[MichalStrehovsky]

Do you have a sample where this saving would be meaningful? I tried the NativeAOT sample in the slon repo but that one only has one type we get rid of and the saving is not very meaningful (can't justify 140 lines of code in the compiler to maintain).