为什么即使在构造函数调用之后，CLR 也会继续检查静态成员的类型构造函数调用？

Question

我了解当一个类型声明一个显式静态构造函数时，即时 (JIT) 编译器会对该类型的每个静态方法和实例构造函数添加检查，以确保之前调用了静态构造函数。

这种行为我可以想象成如下代码（如果我对这个结论有误，请纠正我）：

class  ExplicitConstructor
    {
        private static string myVar;

        // Force “precise” initialization 
        static ExplicitConstructor() { myVar = "hello, world";} 
    
        
        /* CLR: if the type constructor didn't invoked 
                then add a call to the type constructor */
        public static string MyProperty
        {
            get { return myVar; }
        }
        
        /* CLR: if the type constructor didn't invoked 
                then add a call to the type constructor */
        public ExplicitConstructor()
        {
            Console.WriteLine("In instance ctor");
        }

    }

    class ImplicitConstructor 
    { 
        private static string myVar = "hello, world";
        
        public static string MyProperty
        {
            /* CLR: Invoke the type constructor only here */
            get { return myVar; }
        }
        
        public ImplicitConstructor()
        {
            Console.WriteLine("In instance ctor");
        }
    }

根据performance rules，这种行为会对性能产生影响，因为运行时会执行检查以在精确的时间运行类型初始化程序。

[MemoryDiagnoser]
[Orderer(SummaryOrderPolicy.FastestToSlowest)]
[RankColumn]
public class BenchmarkExample
{
    public const int iteration = Int32.MaxValue - 1;

    [Benchmark]
    public void BenchExplicitConstructor()
    {
        for (int i = 0; i < iteration; i++)
        {
            var temp = ExplicitConstructor.MyProperty;
        }
    }

    [Benchmark]
    public void BenchImplicitConstructor()
    {
        for (int i = 0; i < iteration; i++)
        {
            var temp = ImplicitConstructor.MyProperty;
        }
    }

}

Method	Mean	Error	StdDev	Rank	Allocated
BenchImplicitConstructor	982.6 ms	56.64 ms	163.4 ms	1	-
BenchExplicitConstructor	7,361.4 ms	318.19 ms	933.2 ms	2	-

为什么 CLR 不检查该类型的每个静态方法/实例构造函数以确保先前调用了该类型构造函数，而是检查该类型构造函数是否已被调用（仅一次）？

Answer 1

检查静态构造函数是否已在 ExplicitConstructor 中调用的成本被夸大了，因为 JIT 未能优化基准方法中的检查 - 正如 BenchmarkDotNet DisassemblyDiagnoser 生成的 JITd 程序集所示。

; BenchExplicitConstructor()
       push      rsi
       sub       rsp,20
       xor       esi,esi

M00_L00: ; Hot loop
       mov       rcx,7FFE299E97C0
       mov       edx,6
       call      CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE ; static check
       inc       esi
       cmp       esi,7FFFFFFE
       jl        short M00_L00

       add       rsp,20
       pop       rsi
       ret

通过确保在命中热循环之前检查 ExplicitConstructor（并在本例中已初始化）来帮助它导致奇偶校验。

[Benchmark]
public void BenchExplicitConstructor()
{
    _ = ExplicitConstructor.MyProperty; // Explicitly check the class

    for (int i = 0; i < iteration; i++)
    {
        var temp = ExplicitConstructor.MyProperty;
    }
}

Method	Mean	Error	StdDev	Rank	Code Size	Allocated
BenchImplicitConstructor	672.8 ms	0.23 ms	0.18 ms	1	43 B	3,992 B
BenchExplicitConstructor	673.6 ms	1.19 ms	0.93 ms	1	40 B	384 B

为什么 JIT 不自己做呢？ 在一小段代码的上下文中，没有适当的启发式方法对其进行优化。在正常程序的上下文中，这是极不可能错过的。

更新：

这是 #1327 涵盖的已知 JIT 问题，其中讨论 notes 包含循环的方法默认跳过快速 JIT（请参阅 tiered compilation）。这意味着没有提升静态检查（将其从循环体中取出）的初始编译在程序的生命周期内被锁定。

虽然此性能问题目前尚未解决，但相关的feature request 中提到了更简洁的解决方法；使用 Fody 属性而不是不明显的手动提升调用。