前言

本文是Performance Improvements in .NET 7 OSR部分的翻译.下面开始正文:

//原文地址: https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#loop-hoisting-and-cloning

On-Stack Replacement(栈上替换),是在.NET 7中实现JIT的最酷的功能之一.但要真正理解OSR,我们首先需要理解分层编译,所以快速回顾一下…

使用JIT编译器的托管环境必须处理的问题之一是启动和吞吐量之间的权衡.从历史上看,编译器优化的任务是生成执行更快的代码,以便在应用程序或服务运行时实现尽可能最佳的吞吐量.但这种优化需要分析,需要时间,执行所有这些工作会导致启动时间增加,因为程序的所有代码(例如,在web服务器可以服务第一个请求之前需要运行的所有代码)都需要编译.因此,JIT编译器需要做出权衡：以更长的启动时间为代价提高吞吐量,或以降低吞吐量为代价提高启动时间.对于某些类型的应用程序和服务,折衷是一个简单的调用,例如,如果您的服务启动一次,然后运行几天,额外几秒的启动时间并不重要,或者如果您是一个控制台应用程序,将要进行快速计算并退出,启动时间才是最重要的.

但是,JIT如何知道它处于哪个场景中,我们真的希望每个开发人员都知道这些设置和权衡,并相应地配置他们的每个应用程序吗?对此的一个答案是提前编译,它在.NET中采用了多种形式.例如,所有的核心库都是“crossgen”,这意味着它们已经通过一个工具运行,该工具生成了前面提到的R2R格式,生成的二进制文件包含汇编代码,只需要稍加调整即可实际执行；不是每个方法都可以为其生成代码,但足以显著减少启动时间.当然,这种方法也有其自身的缺点,例如,JIT编译器的一个承诺是,它可以利用当前机器/进程的知识进行最佳优化,因此,例如,R2R映像必须假设某个基线指令集(例如,哪些矢量化指令可用),而JIT可以看到哪些实际可用并使用最佳.“分层编译”提供了另一个答案,无论是否使用这些其他提前(AOT)编译解决方案,都可以使用.

分层编译使JIT能够鱼与熊掌兼得.分层编译这个想法很简单:允许JIT多次编译相同的代码.第一次,JIT可以使用尽可能少的优化(少量优化实际上可以使JIT自身的吞吐量更快,因此这些优化仍然适用),生成相当未优化的汇编代码,但速度非常快.当它这样做时,它可以在程序集中添加一些工具来跟踪方法的调用频率.事实证明,在启动路径上使用的许多函数被调用一次,或者可能只调用了几次,优化它们比不优化执行它们需要更多的时间.然后,当方法的插装触发某个阈值时,例如,一个方法已执行30次,工作项将排队重新编译该方法,但这一次JIT可以对其进行所有优化.这被亲切地称为“分层”.一旦重新编译完成,方法的调用站点就会用新高度优化的汇编代码的地址进行修补,未来的调用将采用快速路径.因此,我们获得了更快的启动和更快的持续吞吐量.

然而,一个问题是不适合这种模式的方法.当然,许多性能敏感的方法都相对较快,执行了很多次,但也有大量性能敏感方法只执行了几次,甚至可能只执行一次,但执行需要很长时间,甚至可能是整个过程的持续时间:带循环的方法.因此,默认情况下,分层编译未应用于循环,但可以通过将DOTNET_TC_QuickJitForLoops环境变量设置为1来启用.我们可以通过尝试使用.NET 6的简单控制台应用程序来查看其效果.使用默认设置,运行此应用程序:

class Program
{
    static void Main()
    {
        var sw = new System.Diagnostics.Stopwatch();
        while (true)
        {
            sw.Restart();
            for (int trial = 0; trial < 10_000; trial++)
            {
                int count = 0;
                for (int i = 0; i < char.MaxValue; i++)
                    if (IsAsciiDigit((char)i))
                        count++;
            }
            sw.Stop();
            Console.WriteLine(sw.Elapsed);
        }

        static bool IsAsciiDigit(char c) => (uint)(c - '0') <= 9;
    }
}

输出内容:

00:00:00.5734352
00:00:00.5526667
00:00:00.5675267
00:00:00.5588724
00:00:00.5616028

现在,尝试将DOTNET_TC_QuickJitForLoops设置为1.当我再次运行它时,得到如下数字:

00:00:01.2841397
00:00:01.2693485
00:00:01.2755646
00:00:01.2656678
00:00:01.2679925

换句话说,启用DOTNET_TC_QuickJitForLoops时,需要的时间是不启用时的2.5倍(在.NET6中).这是因为这个主函数从未应用过优化.通过将DOTNET_TC_QuickJitForLoops设置为1,我们说“JIT,请将分层也应用于具有循环的方法”,但这种具有循环的方式只调用一次,因此在整个过程中,它最终保持在“tier-0”,即未优化.现在,让我们对.NET 7进行同样的尝试.无论是否设置了环境变量,我都会再次得到如下数字:

00:00:00.5528889
00:00:00.5562563
00:00:00.5622086
00:00:00.5668220
00:00:00.5589112

但重要的是,这种方法仍然参与了分层.事实上,我们可以通过使用前面提到的DOTNET_JitDisasmSummary=1环境变量来确认.当我设置并再次运行时,我在输出中看到这些行:

4: JIT compiled Program:Main() [Tier0, IL size=83, code size=319]
...
6: JIT compiled Program:Main() [Tier1-OSR @0x27, IL size=83, code size=380]

栈上替换的思想是,方法不仅可以在调用之间替换,而且可以在“栈上”执行时替换.除了为调用计数检测第0层代码外,还为迭代计数检测循环.当迭代超过某个限制时,JIT编译该方法的新的高度优化版本,将所有本地/寄存器状态从当前调用转移到新调用,然后跳到新方法中的适当位置.通过使用前面讨论的DOTNET_JitDisasm环境变量,我们可以看到这一点.将其设置为Program:*以查看为Program类中的所有方法生成的汇编代码,然后再次运行应用程序.您应该看到如下输出:

// Assembly listing for method Program:Main()
// Emitting BLENDED_CODE for X64 CPU with AVX - Windows
// Tier-0 compilation
// MinOpts code
// rbp based frame
// partially interruptible

G_M000_IG01:                ;; offset=0000H
       55                   push     rbp
       4881EC80000000       sub      rsp, 128
       488DAC2480000000     lea      rbp, [rsp+80H]
       C5D857E4             vxorps   xmm4, xmm4
       C5F97F65B0           vmovdqa  xmmword ptr [rbp-50H], xmm4
       33C0                 xor      eax, eax
       488945C0             mov      qword ptr [rbp-40H], rax

G_M000_IG02:                ;; offset=001FH
       48B9002F0B50FC7F0000 mov      rcx, 0x7FFC500B2F00
       E8721FB25F           call     CORINFO_HELP_NEWSFAST
       488945B0             mov      gword ptr [rbp-50H], rax
       488B4DB0             mov      rcx, gword ptr [rbp-50H]
       FF1544C70D00         call     [Stopwatch:.ctor():this]
       488B4DB0             mov      rcx, gword ptr [rbp-50H]
       48894DC0             mov      gword ptr [rbp-40H], rcx
       C745A8E8030000       mov      dword ptr [rbp-58H], 0x3E8

G_M000_IG03:                ;; offset=004BH
       8B4DA8               mov      ecx, dword ptr [rbp-58H]
       FFC9                 dec      ecx
       894DA8               mov      dword ptr [rbp-58H], ecx
       837DA800             cmp      dword ptr [rbp-58H], 0
       7F0E                 jg       SHORT G_M000_IG05

G_M000_IG04:                ;; offset=0059H
       488D4DA8             lea      rcx, [rbp-58H]
       BA06000000           mov      edx, 6
       E8B985AB5F           call     CORINFO_HELP_PATCHPOINT

G_M000_IG05:                ;; offset=0067H
       488B4DC0             mov      rcx, gword ptr [rbp-40H]
       3909                 cmp      dword ptr [rcx], ecx
       FF1585C70D00         call     [Stopwatch:Restart():this]
       33C9                 xor      ecx, ecx
       894DBC               mov      dword ptr [rbp-44H], ecx
       33C9                 xor      ecx, ecx
       894DB8               mov      dword ptr [rbp-48H], ecx
       EB20                 jmp      SHORT G_M000_IG08

G_M000_IG06:                ;; offset=007FH
       8B4DB8               mov      ecx, dword ptr [rbp-48H]
       0FB7C9               movzx    rcx, cx
       FF152DD40B00         call     [Program:<Main>g__IsAsciiDigit|0_0(ushort):bool]
       85C0                 test     eax, eax
       7408                 je       SHORT G_M000_IG07
       8B4DBC               mov      ecx, dword ptr [rbp-44H]
       FFC1                 inc      ecx
       894DBC               mov      dword ptr [rbp-44H], ecx

G_M000_IG07:                ;; offset=0097H
       8B4DB8               mov      ecx, dword ptr [rbp-48H]
       FFC1                 inc      ecx
       894DB8               mov      dword ptr [rbp-48H], ecx

G_M000_IG08:                ;; offset=009FH
       8B4DA8               mov      ecx, dword ptr [rbp-58H]
       FFC9                 dec      ecx
       894DA8               mov      dword ptr [rbp-58H], ecx
       837DA800             cmp      dword ptr [rbp-58H], 0
       7F0E                 jg       SHORT G_M000_IG10

G_M000_IG09:                ;; offset=00ADH
       488D4DA8             lea      rcx, [rbp-58H]
       BA23000000           mov      edx, 35
       E86585AB5F           call     CORINFO_HELP_PATCHPOINT

G_M000_IG10:                ;; offset=00BBH
       817DB800CA9A3B       cmp      dword ptr [rbp-48H], 0x3B9ACA00
       7CBB                 jl       SHORT G_M000_IG06
       488B4DC0             mov      rcx, gword ptr [rbp-40H]
       3909                 cmp      dword ptr [rcx], ecx
       FF1570C70D00         call     [Stopwatch:get_ElapsedMilliseconds():long:this]
       488BC8               mov      rcx, rax
       FF1507D00D00         call     [Console:WriteLine(long)]
       E96DFFFFFF           jmp      G_M000_IG03

// Total bytes of code 222

// Assembly listing for method Program:<Main>g__IsAsciiDigit|0_0(ushort):bool
// Emitting BLENDED_CODE for X64 CPU with AVX - Windows
// Tier-0 compilation
// MinOpts code
// rbp based frame
// partially interruptible

G_M000_IG01:                ;; offset=0000H
       55                   push     rbp
       488BEC               mov      rbp, rsp
       894D10               mov      dword ptr [rbp+10H], ecx

G_M000_IG02:                ;; offset=0007H
       8B4510               mov      eax, dword ptr [rbp+10H]
       0FB7C0               movzx    rax, ax
       83C0D0               add      eax, -48
       83F809               cmp      eax, 9
       0F96C0               setbe    al
       0FB6C0               movzx    rax, al

G_M000_IG03:                ;; offset=0019H
       5D                   pop      rbp
       C3                   ret     

这里有一些相关的事情需要注意.首先，顶部的注释强调了这段代码是如何编译的:

// Tier-0 compilation
// MinOpts code

因此,我们知道这是用最小优化(“MinOpts”)编译的方法的初始版本(“第0层”).第二，注意装配的这一行:

FF152DD40B00         call     [Program:<Main>g__IsAsciiDigit|0_0(ushort):bool]

我们的IsAsciiDigit辅助方法是简单的可内联的,但它没有内联;相反,程序集有一个对它的调用,事实上,我们可以在下面看到为IsAsciiDigit生成的代码(也是“MinOpts”).为什么?因为内联是一种优化(非常重要的优化),但在tier-0中被禁用(因为为了进行良好的内联分析也非常昂贵).第三,我们可以看到JIT输出到检测该方法的代码.这有点复杂,但我会指出相关部分.首先,我们看到:

C745A8E8030000       mov      dword ptr [rbp-58H], 0x3E8

0x3E8是十进制1000的十六进制值,这是在JIT生成方法的优化版本之前循环需要迭代的默认迭代次数(可通过环境变量DOTNET_TC_OnStackReplacement_InitialCounter进行配置).因此,我们看到1000存储在这个堆栈位置.然后,在该方法的后面,我们看到:

G_M000_IG03:                // offset=004BH
       8B4DA8               mov      ecx, dword ptr [rbp-58H]
       FFC9                 dec      ecx
       894DA8               mov      dword ptr [rbp-58H], ecx
       837DA800             cmp      dword ptr [rbp-58H], 0
       7F0E                 jg       SHORT G_M000_IG05

G_M000_IG04:                // offset=0059H
       488D4DA8             lea      rcx, [rbp-58H]
       BA06000000           mov      edx, 6
       E8B985AB5F           call     CORINFO_HELP_PATCHPOINT

G_M000_IG05:                // offset=0067H

生成的代码将该计数器加载到ecx寄存器中,将其递减,存储回,然后查看计数器是否下降到0.如果没有下降,则代码跳转到G_M000_IG05,这是循环其余部分中实际代码的标签.但如果计数器下降到0,JIT将继续将相关状态存储到rcx和edx寄存器中,然后调用CORINFO_HELP_PATCHPOINT helper方法.该助手负责触发优化方法的创建（如果它还不存在）,修复所有适当的跟踪状态,并跳转到新方法.事实上,如果您再次查看运行程序的控制台输出,您将看到主方法的另一个输出:

// Assembly listing for method Program:Main()
// Emitting BLENDED_CODE for X64 CPU with AVX - Windows
// Tier-1 compilation
// OSR variant for entry point 0x23
// optimized code
// rsp based frame
// fully interruptible
// No PGO data
// 1 inlinees with PGO data; 8 single block inlinees; 0 inlinees without PGO data

G_M000_IG01:                // offset=0000H
       4883EC58             sub      rsp, 88
       4889BC24D8000000     mov      qword ptr [rsp+D8H], rdi
       4889B424D0000000     mov      qword ptr [rsp+D0H], rsi
       48899C24C8000000     mov      qword ptr [rsp+C8H], rbx
       C5F877               vzeroupper
       33C0                 xor      eax, eax
       4889442428           mov      qword ptr [rsp+28H], rax
       4889442420           mov      qword ptr [rsp+20H], rax
       488B9C24A0000000     mov      rbx, gword ptr [rsp+A0H]
       8BBC249C000000       mov      edi, dword ptr [rsp+9CH]
       8BB42498000000       mov      esi, dword ptr [rsp+98H]

G_M000_IG02:                // offset=0041H
       EB45                 jmp      SHORT G_M000_IG05
                            align    [0 bytes for IG06]

G_M000_IG03:                // offset=0043H
       33C9                 xor      ecx, ecx
       488B9C24A0000000     mov      rbx, gword ptr [rsp+A0H]
       48894B08             mov      qword ptr [rbx+08H], rcx
       488D4C2428           lea      rcx, [rsp+28H]
       48B87066E68AFD7F0000 mov      rax, 0x7FFD8AE66670

G_M000_IG04:                // offset=0060H
       FFD0                 call     rax ; Kernel32:QueryPerformanceCounter(long):int
       488B442428           mov      rax, qword ptr [rsp+28H]
       488B9C24A0000000     mov      rbx, gword ptr [rsp+A0H]
       48894310             mov      qword ptr [rbx+10H], rax
       C6431801             mov      byte  ptr [rbx+18H], 1
       33FF                 xor      edi, edi
       33F6                 xor      esi, esi
       833D92A1E55F00       cmp      dword ptr [(reloc 0x7ffcafe1ae34)], 0
       0F85CA000000         jne      G_M000_IG13

G_M000_IG05:                // offset=0088H
       81FE00CA9A3B         cmp      esi, 0x3B9ACA00
       7D17                 jge      SHORT G_M000_IG09

G_M000_IG06:                // offset=0090H
       0FB7CE               movzx    rcx, si
       83C1D0               add      ecx, -48
       83F909               cmp      ecx, 9
       7702                 ja       SHORT G_M000_IG08

G_M000_IG07:                // offset=009BH
       FFC7                 inc      edi

G_M000_IG08:                // offset=009DH
       FFC6                 inc      esi
       81FE00CA9A3B         cmp      esi, 0x3B9ACA00
       7CE9                 jl       SHORT G_M000_IG06

G_M000_IG09:                // offset=00A7H
       488B6B08             mov      rbp, qword ptr [rbx+08H]
       48899C24A0000000     mov      gword ptr [rsp+A0H], rbx
       807B1800             cmp      byte  ptr [rbx+18H], 0
       7436                 je       SHORT G_M000_IG12

G_M000_IG10:                // offset=00B9H
       488D4C2420           lea      rcx, [rsp+20H]
       48B87066E68AFD7F0000 mov      rax, 0x7FFD8AE66670

G_M000_IG11:                // offset=00C8H
       FFD0                 call     rax ; Kernel32:QueryPerformanceCounter(long):int
       488B4C2420           mov      rcx, qword ptr [rsp+20H]
       488B9C24A0000000     mov      rbx, gword ptr [rsp+A0H]
       482B4B10             sub      rcx, qword ptr [rbx+10H]
       4803E9               add      rbp, rcx
       833D2FA1E55F00       cmp      dword ptr [(reloc 0x7ffcafe1ae34)], 0
       48899C24A0000000     mov      gword ptr [rsp+A0H], rbx
       756D                 jne      SHORT G_M000_IG14

G_M000_IG12:               // offset=00EFH
       C5F857C0             vxorps   xmm0, xmm0
       C4E1FB2AC5           vcvtsi2sd  xmm0, rbp
       C5FB11442430         vmovsd   qword ptr [rsp+30H], xmm0
       48B9F04BF24FFC7F0000 mov      rcx, 0x7FFC4FF24BF0
       BAE7070000           mov      edx, 0x7E7
       E82E1FB25F           call     CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE
       C5FB10442430         vmovsd   xmm0, qword ptr [rsp+30H]
       C5FB5905E049F6FF     vmulsd   xmm0, xmm0, qword ptr [(reloc 0x7ffc4ff25720)]
       C4E1FB2CD0           vcvttsd2si  rdx, xmm0
       48B94B598638D6C56D34 mov      rcx, 0x346DC5D63886594B
       488BC1               mov      rax, rcx
       48F7EA               imul     rdx:rax, rdx
       488BCA               mov      rcx, rdx
       48C1E93F             shr      rcx, 63
       48C1FA0B             sar      rdx, 11
       4803CA               add      rcx, rdx
       FF1567CE0D00         call     [Console:WriteLine(long)]
       E9F5FEFFFF           jmp      G_M000_IG03

G_M000_IG13:               // offset=014EH
       E8DDCBAC5F           call     CORINFO_HELP_POLL_GC
       E930FFFFFF           jmp      G_M000_IG05

G_M000_IG14:               // offset=0158H
       E8D3CBAC5F           call     CORINFO_HELP_POLL_GC
       EB90                 jmp      SHORT G_M000_IG12

// Total bytes of code 351

这里,我们再次注意到一些有趣的事情.首先,在头文件中我们看到:

// Tier-1 compilation
// OSR variant for entry point 0x23
// optimized code

因此,我们知道这既是优化的“第1层”代码,也是该方法的“OSR变体”.其次,请注意,不再调用IsAsciiDigit方法.相反,我们看到的是,该调用的位置:

G_M000_IG06:                ;; offset=0090H
       0FB7CE               movzx    rcx, si
       83C1D0               add      ecx, -48
       83F909               cmp      ecx, 9
       7702                 ja       SHORT G_M000_IG08

这是将一个值加载到rcx中,从中减去48(48是“0”字符的十进制ASCII值),并将结果值与9进行比较.听起来很像我们的IsasciidGit实现( (uint)(c-“0”)<=9 ),不是吗？这是因为它是.帮助程序成功地内联到现在优化的代码中.

很好,现在在.NET7中,我们可以在很大程度上避免启动和吞吐量之间的权衡,因为OSR使分层编译能够应用于所有方法,甚至是那些长期运行的方法.许多提交开始启用此功能,包括过去几年中的许多提交,但是所有的功能在发布时都被禁用了.由于dotnet/runtime#62831在Arm64上实现了对OSR的支持(之前仅实现了x64支持),以及dotnet/Runtime#63406和dotnet/runtime#65609修改了如何OSR导入和epilog的处理,dotnet/runtime#65675在默认情况下启用OSR(DOTNET_TC_QuickJitForLoops=1).

但是,分层编译和OSR不仅仅是关于启动(尽管它们在那里当然非常有价值).他们还将进一步提高吞吐量.尽管分层编译最初被设想为一种在不影响吞吐量的情况下优化启动的方法,但它已经远远不止于此.JIT可以在tier-0期间了解到关于方法的各种信息,然后可以用于tier-1.例如,执行的tier-2代码意味着该方法访问的任何静态都将被初始化,这意味着任何只读静态不仅在执行tier-3代码时已经初始化,而且它们的值永远不会改变.这反过来意味着,任何原始类型的只读静态(如bool、int等)都可以被视为常量,而不是静态只读字段,并且在第1层编译期间,JIT可以优化它们,就像优化常量一样.例如,在将DOTNET_JitDisasm设置为Program:Test后,尝试运行以下简单程序:

using System.Runtime.CompilerServices;

class Program
{
    static readonly bool Is64Bit = Environment.Is64BitProcess;

    static int Main()
    {
        int count = 0;
        for (int i = 0; i < 1_000_000_000; i++)
            if (Test())
                count++;
        return count;
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static bool Test() => Is64Bit;
}

当我这样做时,我得到以下输出:

// Assembly listing for method Program:Test():bool
// Emitting BLENDED_CODE for X64 CPU with AVX - Windows
// Tier-0 compilation
// MinOpts code
// rbp based frame
// partially interruptible

G_M000_IG01:                ;; offset=0000H
       55                   push     rbp
       4883EC20             sub      rsp, 32
       488D6C2420           lea      rbp, [rsp+20H]

G_M000_IG02:                ;; offset=000AH
       48B9B8639A3FFC7F0000 mov      rcx, 0x7FFC3F9A63B8
       BA01000000           mov      edx, 1
       E8C220B25F           call     CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE
       0FB60545580C00       movzx    rax, byte  ptr [(reloc 0x7ffc3f9a63ea)]

G_M000_IG03:                ;; offset=0025H
       4883C420             add      rsp, 32
       5D                   pop      rbp
       C3                   ret

// Total bytes of code 43

// Assembly listing for method Program:Test():bool
// Emitting BLENDED_CODE for X64 CPU with AVX - Windows
// Tier-1 compilation
// optimized code
// rsp based frame
// partially interruptible
// No PGO data

G_M000_IG01:                ;; offset=0000H

G_M000_IG02:                ;; offset=0000H
       B801000000           mov      eax, 1

G_M000_IG03:                ;; offset=0005H
       C3                   ret

// Total bytes of code 6

注意,我们再次看到程序的两个输出:Test方法的汇编代码.首先,我们看到“Tier-0”代码,它正在访问静态（注意调用CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE指令).但是,我们看到了“Tier-1”代码,其中所有的开销都消失了,取而代之的是mov eax,1.由于必须执行“Tier-0”代码才能分层,“Tier-2”代码是在知道静态只读bool IS64位字段的值为真的情况下生成的（1),因此,整个方法是将值1存储到用于返回值的eax寄存器中.

这非常有用,现在编写组件时都考虑到了分层.考虑一下新的Regex源代码生成器,这将在后面的文章中讨论(Roslyn源代码生成器是几年前引入的;就像Roslyn分析器能够插入编译器并基于编译器从源代码中学习到的所有数据提供额外的诊断一样,Roslyn源代码生成器能够分析相同的数据,然后用额外的源代码进一步增加编译单元).Regex源生成器应用基于此的dotnet/runtime#67775技术.Regex支持设置流程范围的超时,该超时将应用于没有显式设置超时的Regex实例.这意味着,即使设置这样一个进程范围的超时非常罕见,Regex源生成器仍然需要输出与超时相关的代码,以备需要.它通过输出一些helper来实现,像这样:

static class Utilities
{
    internal static readonly TimeSpan s_defaultTimeout = AppContext.GetData("REGEX_DEFAULT_MATCH_TIMEOUT") is TimeSpan timeout ? timeout : Timeout.InfiniteTimeSpan;
    internal static readonly bool s_hasTimeout = s_defaultTimeout != Timeout.InfiniteTimeSpan;
}

然后调用的方式,如下所示:

if (Utilities.s_hasTimeout)
{
    base.CheckTimeout();
}

在第0层中,这些检查仍然会在程序集代码中发出,但在吞吐量很重要的第1层中,如果没有设置相关的AppContext开关,那么s_defaultTimeout将会是Timeout.infinittimeespan,此时s_hasTimeout将为false.由于s_hasTimeout是一个静态的只读bool, JIT将能够将其视为const,并且所有的条件,如if (Utilities.s_hasTimeout)将被视为与if (false)相等,并从汇编代码中完全清除为死代码.

但是,这有点老生常谈了.自从.NET Core 3.0引入分层编译以来,JIT就能够进行这样的优化.不过,现在在.NET 7中,在OSR中,它也可以在默认情况下对带有循环的方法进行优化(因此启用了类似于正则表达式的情况).然而,当OSR与另一个令人兴奋的特性：动态PGO相结合时,OSR的真正魔力开始发挥作用.

因JIT部分内容太多,这里进行拆分,PGO拆分为一篇博文.

个人能力有限,如果您发现有什么不对,请私信我

如果您觉得对您有用的话,可以点个赞或者加个关注,欢迎大家一起进行技术交流