.NET8顶级调试lldb观察FOH堆字符串分配

发布时间 2023-12-08 07:58:45作者: 江湖评谈

前言

好久没有动用LLDB了,这种未来的下一代高性能调试器应该是用在Linux内核系统的Arm64/Riscv64/X64系统指令集上的,LLDB Debug .NET有点杀鸡用牛刀。本篇通过它来看下FOH也就是.NET8里面优化字符串,为了提高其性能增加的FOH堆分配过程。关于FOH可以参考:.NET8极致性能优化Non-GC Heap

详细

来看一个简单的例子:

public static string GetPrefix() => "https://";
static void Main(string[] args)
{
   GetPrefix();
   GC.Collect();
   Console.ReadLine();
}

函数GetPrefix里面的字符串“https://”就是被分配到FOH堆里面的,如何验证呢?

首先通过LLDB把CLR运行到托管Main入口

(lldb) b RunMainInternal
Breakpoint 7: where = libcoreclr.so`RunMainInternal(Param*) at assembly.cpp:1257, address = 0x00007ffff6d43930
(lldb) r
Process 2697 launched: '/home/tang/opt/dotnet/debug_clr/clrrun' (x86_64)
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = breakpoint 6.1 7.1
    frame #0: 0x00007ffff6d43930 libcoreclr.so`RunMainInternal(pParam=0x00007ffff7faaab6) at assembly.cpp:1257
   1254  } param;
   1255  
   1256  static void RunMainInternal(Param* pParam)
-> 1257  {
   1258      MethodDescCallSite  threadStart(pParam->pFD);
   1259  
   1260      PTRARRAYREF StrArgArray = NULL;
(lldb) 

然后把其运行到JIT前置入口

(lldb) b PreStubWorker
Breakpoint 8: where = libcoreclr.so`::PreStubWorker(TransitionBlock *, MethodDesc *) at prestub.cpp:1865, address = 0x00007ffff6ee6c10
(lldb) c
Process 2697 resuming
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = breakpoint 8.1
    frame #0: 0x00007ffff6ee6c10 libcoreclr.so`::PreStubWorker(pTransitionBlock=0x00000000ffffcb38, pMD=0x0000000155608c70) at prestub.cpp:1865
   1862  // returns a pointer to the new code for the prestub's convenience.
   1863  //=============================================================================
   1864  extern "C" PCODE STDCALL PreStubWorker(TransitionBlock* pTransitionBlock, MethodDesc* pMD)
-> 1865  {
   1866      PCODE pbRetVal = NULL;
   1867  
   1868      BEGIN_PRESERVE_LAST_ERROR;

此时可以看下当前JIT编译的函数是谁,这里需要先n命令单步一下

(lldb) n
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = step over
    frame #0: 0x00007ffff6ee6c36 libcoreclr.so`::PreStubWorker(pTransitionBlock=0x00007fffffffc648, pMD=0x00007fff78f56b70) at prestub.cpp:1866:11
   1863  //=============================================================================
   1864  extern "C" PCODE STDCALL PreStubWorker(TransitionBlock* pTransitionBlock, MethodDesc* pMD)
   1865  {
-> 1866      PCODE pbRetVal = NULL;
   1867  
   1868      BEGIN_PRESERVE_LAST_ERROR;

然后通过微软提供的sos.dll Dump下当前的函数描述结构体MethodDesc,pMD是传过来的函数参数,也即是MethodDesc的变量

(lldb) sos dumpmd pMD
Method Name:          ConsoleApp1.Test+Program.Main(System.String[])
Class:                00007fff78f97530
MethodTable:          00007fff78f56c08
mdToken:              0000000006000008
Module:               00007fff78f542d0
IsJitted:             no
Current CodeAddr:     ffffffffffffffff
Version History:
  ILCodeVersion:      0000000000000000
  ReJIT ID:           0
  IL Addr:            00007ffff7faa2aa
     CodeAddr:           0000000000000000  (MinOptJitted)
     NativeCodeVersion:  0000000000000000

可以清晰的看到Method Name就是ConsoleApp1.Test+Program.Main,OK这一步确定了,我们下面继续寻找字符串分配到FOH,首先删掉前面所有的断点

(lldb) br del
About to delete all breakpoints, do you want to do that?: [Y/n] y
All breakpoints removed. (3 breakpoints)

在TryAllocateObject 函数上下断,它是分配托管内存的函数

(lldb) b TryAllocateObject
Breakpoint 9: 2 locations.

运行到此处

(lldb) c
Process 2697 resuming
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = breakpoint 9.1
    frame #0: 0x00007ffff70300c0 libcoreclr.so`FrozenObjectHeapManager::TryAllocateObject(this=0x00007fffffff80b8, type=0x00000008017fa948, objectSize=140737488322759, publish=false) at frozenobjectheap.cpp:22
   19    // May return nullptr if object is too large (larger than FOH_COMMIT_SIZE)
   20    // in such cases caller is responsible to find a more appropriate heap to allocate it
   21    Object* FrozenObjectHeapManager::TryAllocateObject(PTR_MethodTable type, size_t objectSize, bool publish)
-> 22    {
   23        CONTRACTL
   24        {
   25            THROWS;

这个函数就是字符串分配到FOH堆的地方,通过它的函数所在的类名即可看出FrozenObjectHeapManager,但是我们依然还是需要验证下。继续n单步这个函数的返回的地方,也就是如下代码:

 202
-> 203       return object;

此时的这个object变量就是示例里面字符串的“https://”的对象地址,看下它的地址值

(lldb) p/x object
(Object *) $14 = 0x00007fffe6bff8c0

记住这个值:0x00007fffe6bff8c0,后面会把它和GC堆的范围进行一个比较。如果它不在GC堆范围,说明.NET8的字符串确实分配在了FOH堆里面。

我们继续单步向下,运行到这个对象被赋值字符串的地方

STRINGREF AllocateStringObject(EEStringData *pStringData, bool preferFrozenObjHeap, bool* pIsFrozen)
{
    //此处省略
   memcpyNoGCRefs(strDest, pStringData->GetStringBuffer(), cCount*sizeof(WCHAR));

    //此处省略
}

然后看下它的内存:

(lldb) memory re 0x00007fffe6bff8c0
0x7fffe6bff8c0: 68 00 74 00 74 00 70 00 73 00 3a 00 2f 00 2f 00  h.t.t.p.s.:././.
0x7fffe6bff8dc: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

它确实是https字符串的对象地址。没有问题。
避免干扰,此时我们再次删除所有断点

(lldb) br del
About to delete all breakpoints, do you want to do that?: [Y/n] y
All breakpoints removed. (1 breakpoint)

然后在函数is_in_find_object_range处下断,它是在GC回收的时候,判断当前的对象地址是否在GC堆里面,如果是则进行对象标记,如果不是直接返回。可以通过这个获取GC堆的范围,运行到此处

(lldb) b is_in_find_object_range
(lldb) c
Process 2697 resuming
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = breakpoint 13.8
    frame #0: 0x00007ffff72d881d libcoreclr.so`WKS::GCHeap::Promote(Object**, ScanContext*, unsigned int) [inlined] WKS::gc_heap::is_in_find_object_range(o=0x0000000000000000) at gc.cpp:7906:11
   7903  inline
   7904  bool gc_heap::is_in_find_object_range (uint8_t* o)
   7905  {
-> 7906      if (o == nullptr)
   7907      {
   7908          return false;
   7909      }

单步n

(lldb) n
Process 2697 stopped
* thread #1, name = 'clrrun', stop reason = step over
    frame #0: 0x00007ffff72d8831 libcoreclr.so`WKS::GCHeap::Promote(Object**, ScanContext*, unsigned int) [inlined] WKS::gc_heap::is_in_find_object_range(o="@\x9b\xd6x\xff\U0000007f") at gc.cpp:7911:14
   7908          return false;
   7909      }
   7910  #if defined(USE_REGIONS) && defined(FEATURE_CONSERVATIVE_GC)
-> 7911      return ((o >= g_gc_lowest_address) && (o < bookkeeping_covered_committed));
   7912  #else //USE_REGIONS && FEATURE_CONSERVATIVE_GC
   7913      if ((o >= g_gc_lowest_address) && (o < g_gc_highest_address))
   7914      {

注意,此时我们看到了GC堆的一个范围,也就是变量g_gc_lowest_address和变量g_gc_highest_address,看下它们的地址范围

(lldb) p/x g_gc_lowest_address 
(uint8_t *) $17 = 0x00007fbf68000000 ""
(lldb) p/x g_gc_highest_address
(uint8_t *) $18 = 0x00007fff68000000 "0"

上面很明显了,GC堆的范围起始地址:0x00007fbf68000000 ,结束地址:0x00007fff68000000 。而字符串“https://”的对象地址是0x00007fffe6bff8c0,很明显它不在GC堆的范围内。

以上通过分配一个字符串到FOH堆,后调用一个GC.Collect()查看GC堆的范围,对FOH对象地址和GC堆范围进行一个判断,为一个非常简单的FOH字符串分配验证。

欢迎加入C#12/.NET8最新技术交流群

结尾

作者:jianghupt
原文:.NET8顶级调试lldb观察FOH堆字符串分配
公众号:jianghupt,文章首发,欢迎关注