为什么结构对齐依赖于字段类型是基元类型还是用户定义类型？

Question

在Noda Time v2中，我们正在转向纳秒分辨率。这意味着我们不能再使用8字节整数来表示我们感兴趣的整个时间范围。这促使我调查Noda Time（许多）结构的内存使用情况，这反过来又让我发现了CLR对齐决策中的一个小怪异之处。

首先，我意识到这是一个实现决策，默认行为可能随时改变。我意识到我可以使用StructLayout和FieldOffset对其进行修改，但如果可能的话，我宁愿想出一个不需要这样做的解决方案。

我的核心场景是，我有一个结构，其中包含一个引用类型字段和两个其他值类型字段，这些字段是int的简单包装。我曾希望在64位CLR上将其表示为16个字节（8个用于参考，4个用于其他每个字节），但出于某种原因，它使用的是24个字节。顺便说一句，我正在使用阵列测量空间-我知道在不同的情况下布局可能会有所不同，但这感觉是一个合理的起点。

这是一个演示该问题的示例程序：

using System;
using System.Runtime.InteropServices;

#pragma warning disable 0169

struct Int32Wrapper
{
    int x;
}

struct TwoInt32s
{
    int x, y;
}

struct TwoInt32Wrappers
{
    Int32Wrapper x, y;
}

struct RefAndTwoInt32s
{
    string text;
    int x, y;
}

struct RefAndTwoInt32Wrappers
{
    string text;
    Int32Wrapper x, y;
}    

class Test
{
    static void Main()
    {
        Console.WriteLine("Environment: CLR {0} on {1} ({2})",
            Environment.Version,
            Environment.OSVersion,
            Environment.Is64BitProcess ? "64 bit" : "32 bit");
        ShowSize<Int32Wrapper>();
        ShowSize<TwoInt32s>();
        ShowSize<TwoInt32Wrappers>();
        ShowSize<RefAndTwoInt32s>();
        ShowSize<RefAndTwoInt32Wrappers>();
    }

    static void ShowSize<T>()
    {
        long before = GC.GetTotalMemory(true);
        T[] array = new T[100000];
        long after  = GC.GetTotalMemory(true);        
        Console.WriteLine("{0}: {1}", typeof(T),
                          (after - before) / array.Length);
    }
}

以及我笔记本电脑上的编译和输出：

c:\Users\Jon\Test>csc /debug- /o+ ShowMemory.cs
Microsoft (R) Visual C# Compiler version 12.0.30501.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.


c:\Users\Jon\Test>ShowMemory.exe
Environment: CLR 4.0.30319.34014 on Microsoft Windows NT 6.2.9200.0 (64 bit)
Int32Wrapper: 4
TwoInt32s: 8
TwoInt32Wrappers: 8
RefAndTwoInt32s: 16
RefAndTwoInt32Wrappers: 24

所以：

• 如果没有引用类型字段，CLR很乐意将Int32Wrapper字段打包在一起（两个Int32Wrapper的大小为8）
• 即使有引用类型字段，CLR仍然乐于将int字段打包在一起（RefAndTwoInt32s的大小为16）
• 将这两个字段结合起来，每个Int32Wrapper字段似乎被填充/对齐为8个字节。（RefAndTwoInt32Wrappers的大小为24。）
• 在调试器中运行相同的代码（但仍然是发布版本）显示大小为12

其他一些实验也得出了类似的结果：

• 将引用类型字段放在值类型字段之后没有帮助
• 使用对象而不是字符串没有帮助（我希望它是“任何引用类型”）
• 在引用周围使用另一个结构作为“包装器”没有帮助
• 使用泛型结构作为引用的包装没有帮助
• 如果我继续添加字段（为了简单起见成对添加），int字段仍计4个字节，而Int32Wrapper字段计8个字节
• 将[StructLayout（LayoutKind.Sequential，Pack=4）]添加到每个可见的结构不会改变结果

是否有人对此有任何解释（最好是参考文档）或建议我如何向CLR提示我希望在不指定常量字段偏移量的情况下打包字段？




Answer 1

摘要请参阅上面@Hans Passant的答案。布局顺序不起作用

一些测试：

它肯定只在64位上，并且对象引用“毒害”了结构。32位满足您的期望：

Environment: CLR 4.0.30319.34209 on Microsoft Windows NT 6.2.9200.0 (32 bit)
ConsoleApplication1.Int32Wrapper: 4
ConsoleApplication1.TwoInt32s: 8
ConsoleApplication1.TwoInt32Wrappers: 8
ConsoleApplication1.ThreeInt32Wrappers: 12
ConsoleApplication1.Ref: 4
ConsoleApplication1.RefAndTwoInt32s: 12
ConsoleApplication1.RefAndTwoInt32Wrappers: 12
ConsoleApplication1.RefAndThreeInt32s: 16
ConsoleApplication1.RefAndThreeInt32Wrappers: 16

一旦添加了对象引用，所有结构将扩展为8字节，而不是4字节大小。扩展测试：

Environment: CLR 4.0.30319.34209 on Microsoft Windows NT 6.2.9200.0 (64 bit)
ConsoleApplication1.Int32Wrapper: 4
ConsoleApplication1.TwoInt32s: 8
ConsoleApplication1.TwoInt32Wrappers: 8
ConsoleApplication1.ThreeInt32Wrappers: 12
ConsoleApplication1.Ref: 8
ConsoleApplication1.RefAndTwoInt32s: 16
ConsoleApplication1.RefAndTwoInt32sSequential: 16
ConsoleApplication1.RefAndTwoInt32Wrappers: 24
ConsoleApplication1.RefAndThreeInt32s: 24
ConsoleApplication1.RefAndThreeInt32Wrappers: 32
ConsoleApplication1.RefAndFourInt32s: 24
ConsoleApplication1.RefAndFourInt32Wrappers: 40

正如您所看到的，一旦添加引用，每个Int32Wrapper就会变成8个字节，因此不是简单的对齐。我缩小了数组分配，以防它是不同对齐的LoH分配。

Answer 2

编辑2

struct RefAndTwoInt32Wrappers
{
    public int x;
    public string s;
}

此代码将8字节对齐，因此结构将有16个字节。相比之下：

struct RefAndTwoInt32Wrappers
{
    public int x,y;
    public string s;
}

将对齐4个字节，因此此结构也将有16个字节。所以这里的基本原理是CLR中的结构分配是由最对齐的字段的数量决定的，类显然不能这样做，所以它们将保持8个字节对齐。

现在，如果我们将所有这些结合起来，创建结构：

struct RefAndTwoInt32Wrappers
{
    public int x,y;
    public Int32Wrapper z;
    public string s;
}

它将有24个字节{x， y}每个字节有4个字节，{z， s}将有8个字节。一旦我们在结构中引入ref类型，CLR将始终对齐我们的自定义结构以匹配类对齐。

struct RefAndTwoInt32Wrappers
{
    public Int32Wrapper z;
    public long l;
    public int x,y;  
}

此代码将有24个字节，因为Int32Wrapper将与long对齐。因此自定义结构包装器将始终对齐结构中最高/最佳对齐的字段或它自己的内部最重要的字段。因此，对于对齐8字节的ref字符串，结构包装器将与之对齐。

struct中的结束自定义结构字段将始终与结构中对齐程度最高的实例字段对齐。现在，如果我不确定这是否是一个bug，但没有一些证据，我会坚持我的观点，这可能是一个有意识的决定。

编辑

实际上，只有在堆上分配时，大小才是准确的，但结构本身的大小较小（字段的确切大小）。进一步的分析表明，这可能是CLR代码中的一个bug，但需要有证据支持。

我将检查cli代码，如果找到有用的东西，我将发布进一步的更新。

这是. NET mem分配器使用的对齐策略。

public static RefAndTwoInt32s[] test = new RefAndTwoInt32s[1];

static void Main()
{
    test[0].text = "a";
    test[0].x = 1;
    test[0].x = 1;

    Console.ReadKey();
}

此代码使用编译。x64下的net40在WinDbg中可以执行以下操作：

让我们先在堆中找到类型：

    0:004> !dumpheap -type Ref
       Address               MT     Size
0000000003e72c78 000007fe61e8fb58       56    
0000000003e72d08 000007fe039d3b78       40    

Statistics:
              MT    Count    TotalSize Class Name
000007fe039d3b78        1           40 RefAndTwoInt32s[]
000007fe61e8fb58        1           56 System.Reflection.RuntimeAssembly
Total 2 objects

一旦我们有了它，让我们看看这个地址下面有什么：

    0:004> !do 0000000003e72d08
Name:        RefAndTwoInt32s[]
MethodTable: 000007fe039d3b78
EEClass:     000007fe039d3ad0
Size:        40(0x28) bytes
Array:       Rank 1, Number of elements 1, Type VALUETYPE
Fields:
None

我们看到这是一个ValueType，它是我们创建的。由于这是一个数组，我们需要获取数组中单个元素的ValueType def：

    0:004> !dumparray -details 0000000003e72d08
Name:        RefAndTwoInt32s[]
MethodTable: 000007fe039d3b78
EEClass:     000007fe039d3ad0
Size:        40(0x28) bytes
Array:       Rank 1, Number of elements 1, Type VALUETYPE
Element Methodtable: 000007fe039d3a58
[0] 0000000003e72d18
    Name:        RefAndTwoInt32s
    MethodTable: 000007fe039d3a58
    EEClass:     000007fe03ae2338
    Size:        32(0x20) bytes
    File:        C:\ConsoleApplication8\bin\Release\ConsoleApplication8.exe
    Fields:
                      MT    Field   Offset                 Type VT     Attr            Value Name
        000007fe61e8c358  4000006        0            System.String      0     instance     0000000003e72d30     text
        000007fe61e8f108  4000007        8             System.Int32      1     instance                    1     x
        000007fe61e8f108  4000008        c             System.Int32      1     instance                    0     y

该结构实际上是32个字节，因为它的16个字节用于填充，因此实际上每个结构从一开始就至少有16个字节的大小。

如果从ints中添加16个字节，并将字符串引用添加到：000000000 3E72D18 8 8字节EE/padding，则最终将达到000000000 3E72D30，这是字符串引用的起始点，并且由于所有引用都是从其第一个实际数据字段中填充8字节，因此这弥补了此结构的32字节。

让我们看看字符串是否真的是这样填充的：

0:004> !do 0000000003e72d30    
Name:        System.String
MethodTable: 000007fe61e8c358
EEClass:     000007fe617f3720
Size:        28(0x1c) bytes
File:        C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:      a
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007fe61e8f108  40000aa        8         System.Int32  1 instance                1 m_stringLength
000007fe61e8d640  40000ab        c          System.Char  1 instance               61 m_firstChar
000007fe61e8c358  40000ac       18        System.String  0   shared           static Empty
                                 >> Domain:Value  0000000001577e90:NotInit  <<

现在让我们以同样的方式分析上述程序：

public static RefAndTwoInt32Wrappers[] test = new RefAndTwoInt32Wrappers[1];

static void Main()
{
    test[0].text = "a";
    test[0].x.x = 1;
    test[0].y.x = 1;

    Console.ReadKey();
}

0:004> !dumpheap -type Ref
     Address               MT     Size
0000000003c22c78 000007fe61e8fb58       56    
0000000003c22d08 000007fe039d3c00       48    

Statistics:
              MT    Count    TotalSize Class Name
000007fe039d3c00        1           48 RefAndTwoInt32Wrappers[]
000007fe61e8fb58        1           56 System.Reflection.RuntimeAssembly
Total 2 objects

我们的结构现在是48字节。

0:004> !dumparray -details 0000000003c22d08
Name:        RefAndTwoInt32Wrappers[]
MethodTable: 000007fe039d3c00
EEClass:     000007fe039d3b58
Size:        48(0x30) bytes
Array:       Rank 1, Number of elements 1, Type VALUETYPE
Element Methodtable: 000007fe039d3ae0
[0] 0000000003c22d18
    Name:        RefAndTwoInt32Wrappers
    MethodTable: 000007fe039d3ae0
    EEClass:     000007fe03ae2338
    Size:        40(0x28) bytes
    File:        C:\ConsoleApplication8\bin\Release\ConsoleApplication8.exe
    Fields:
                      MT    Field   Offset                 Type VT     Attr            Value Name
        000007fe61e8c358  4000009        0            System.String      0     instance     0000000003c22d38     text
        000007fe039d3a20  400000a        8             Int32Wrapper      1     instance     0000000003c22d20     x
        000007fe039d3a20  400000b       10             Int32Wrapper      1     instance     0000000003c22d28     y

这里的情况是一样的，如果我们添加到000000000 3C22D18 8 8字节的字符串ref，我们将在第一个Int包装的开头结束，其中的值实际上指向我们所在的地址。

现在我们可以看到，每个值都是一个对象引用，让我们再次通过查看000000000 3C22D20来确认这一点。

0:004> !do 0000000003c22d20
<Note: this object has an invalid CLASS field>
Invalid object

事实上，这是正确的，因为它是一个结构，如果这是obj或vt，地址不会告诉我们任何信息。

0:004> !dumpvc 000007fe039d3a20   0000000003c22d20    
Name:        Int32Wrapper
MethodTable: 000007fe039d3a20
EEClass:     000007fe03ae23c8
Size:        24(0x18) bytes
File:        C:\ConsoleApplication8\bin\Release\ConsoleApplication8.exe
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007fe61e8f108  4000001        0         System.Int32  1 instance                1 x

所以实际上，这更像是一种联合类型，这次将对齐8字节（所有填充都将与父结构对齐）。如果不是这样，那么我们最终将得到20个字节，这不是最佳的，因此mem分配器将永远不会允许这样的情况发生。如果你再做一次计算，就会发现这个结构确实有40个字节的大小。

因此，如果您想对内存更加保守，您不应该将其打包为结构自定义结构类型，而是使用简单的数组。另一种方法是在堆外分配内存（例如VirtualAllocEx），这样您就可以获得自己的内存块并按照您想要的方式管理它。

这里的最后一个问题是为什么我们会突然得到这样的布局。好吧，如果您将int[]增量和struct[]的jed代码和性能与计数器字段增量进行比较，第二个将生成一个8字节对齐的地址作为联合，但当jed时，这将转换为更优化的汇编代码（单个LEA vs多个MOV）。然而，在这里描述的情况下，性能实际上会更差，所以我的看法是这与底层CLR实现是一致的，因为它是一种可以有多个字段的自定义类型，因此放置起始地址而不是值可能更容易/更好（因为这是不可能的）并在那里进行结构填充，从而导致更大的字节大小。

Answer 3

我认为这是一个错误。您看到了自动布局的副作用，它喜欢将非平凡字段与64位模式下8字节倍数的地址对齐。即使显式应用了StructLayout（LayoutKind.Sequential）属性，也会发生这种情况。这是不应该发生的。

您可以通过公开结构成员并附加如下测试代码来查看它：

    var test = new RefAndTwoInt32Wrappers();
    test.text = "adsf";
    test.x.x = 0x11111111;
    test.y.x = 0x22222222;
    Console.ReadLine();      // <=== Breakpoint here

遇到断点时，请使用调试Windows内存内存1。切换到4字节整数并输入<代码>

 0x000000E928B5DE98  0ed750e0 000000e9 11111111 00000000 22222222 00000000 

0xe90ed750e0是我的机器（不是你的机器）上的字符串指针。您可以很容易地看到Int32Wrappers，额外的4个字节的填充将大小变为24个字节。返回结构并将字符串放在最后。重复上述步骤，您将看到字符串指针仍然位于第一位。违反了LayoutKind。按顺序，您得到了LayoutKind。自动。

很难说服微软来解决这个问题，它这样做已经太久了，所以任何改变都会破坏某些东西。CLR只会尝试对结构的托管版本进行尊重，并使其可blittable，但通常很快就会放弃。对于任何包含DateTime的结构来说都是出了名的。只有在封送结构时，才能获得真正的LayoutKind保证。封送的版本当然是16字节，就像封送一样。SizeOf（）将告诉您。

使用LayoutKind。显式修复了它，而不是您想听到的。