Suboptimal field layout when an object is wrapped in a struct

[MihaZupan]

Consider the following type definitions:

public abstract class Base1
{
    private object _object;
    private byte _byte;
}
public abstract class Base2
{
    private WrappedObject _object;
    private byte _byte;

    private struct WrappedObject
    {
        private object _object;
    }
}

public sealed class Derived1 : Base1
{
    private byte _byte;
}
public sealed class Derived2 : Base2
{
    private byte _byte;
}

Derived1 will group the two byte fields together with 6 bytes of padding.
Derived2 will store the two byte fields separately and add 7 bytes of padding after each one.
As a result, Derived1 takes up 16 bytes (after the header and MT), but Derived2 takes up 24.

Is such a layout intentional, or just a random inefficiency?

Hit in #62981

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.

[jkoritzinsky]

This layout (at least as of writing this response) is intentional. The auto-layout algorithm places primitive and ref (object or class-types) fields first and user-defined value types last, which is why you see WrappedObject after the padding in Derived2. There’s also a mechanism for derived types to place small primitive fields in any trailing padding in the base type, which is what you see happening in the Derived1 case.

This is something that can be improved on, it just takes a bit of work (and can only be done when we take an R2R breaking change, so either some time in the next few months or after .NET 7).