Microsoft MVP성태의 닷넷 이야기
.NET Framework: 957. C# - static 필드의 정보가 GC Heap에 저장될까요? [링크 복사], [링크+제목 복사],
조회: 11026
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 5개 있습니다.)
디버깅 기술: 112. windbg - 닷넷 메모리 덤프에서 전역 객체의 내용을 조사하는 방법
; https://www.sysnet.pe.kr/2/0/11460

디버깅 기술: 115. windbg - 닷넷 메모리 덤프에서 정적(static) 필드 값을 조사하는 방법
; https://www.sysnet.pe.kr/2/0/11487

.NET Framework: 957. C# - static 필드의 정보가 GC Heap에 저장될까요?
; https://www.sysnet.pe.kr/2/0/12387

디버깅 기술: 182. windbg - 닷넷 메모리 덤프에서 AppDomain에 걸친 정적(static) 필드 값을 조사하는 방법
; https://www.sysnet.pe.kr/2/0/13004

디버깅 기술: 193. Windbg - ThreadStatic 필드 값을 조사하는 방법
; https://www.sysnet.pe.kr/2/0/13414




C# - static 필드의 정보가 GC Heap에 저장될까요?

아래의 질문에서,

C# 정적 클래스
; https://forum.dotnetdev.kr/t/c/156

다른 건 그냥 넘어가고, static 필드의 값이 과연 어디에 저장되느냐... 하는 것이 다소 흥미로울 수 있습니다. 사실 이에 대해서는 예전 글에서,

windbg - 닷넷 메모리 덤프에서 정적(static) 필드 값을 조사하는 방법
; https://www.sysnet.pe.kr/2/0/11487

이미 유사하게 다뤘습니다. 그래도 ^^ 이참에 전용 주제로 한 번 다뤄보도록 하겠습니다.




실습을 위해 다음과 같이 간단한 코드를 작성해 보고,

using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Press any key to continue...");
        Console.ReadLine();

        AccessField();

        Console.WriteLine("Press any key to exit...");
        Console.ReadLine();
    }

    private unsafe static void AccessField()
    {
        Console.WriteLine(MyClass.Age);

        fixed (int* ptr = &(MyClass.Age))
        {
            IntPtr addr = new IntPtr(ptr);
            Console.WriteLine("0x" + addr.ToInt64().ToString("x"));
        }
    }
}

public class MyClass
{
    static public int Age = 5;
    static public string Name = "tester";}
}

실행 후, 첫 번째 Console.ReadLine에 멈췄을 때 windbg로 연결합니다. 당연히 지금 시점에는 MyClass의 어떠한 인스턴스도 new를 하지 않았으므로 GC Heap에는 MyClass 타입과 관련한 정보를 찾을 수 없습니다.

0:000> !dumpheap -type MyClass
         Address               MT     Size

Statistics:
              MT    Count    TotalSize Class Name
Total 0 objects

게다가 Type 정보 자체도 아직 메모리에 로드하지 않았음을 !name2ee 명령어 실행 결과로 알 수 있습니다.

0:000> !name2ee ConsoleApp1!MyClass
Module:      00007ff916485158
Assembly:    ConsoleApp1.exe
Token:       0000000002000003
MethodTable: <not loaded yet>
EEClass:     <not loaded yet>
Name:        MyClass

자, 그럼 계속 진행하기 위해 'g' 키를 누르고 MyClass.Age 필드를 접근하기 위해 enter 키를 한 번 누르면 화면에는 이런 식으로 출력이 됩니다.

Press any key to continue...

5
0x7ff9164857ec
Press any key to exit...

당연히 이 시점에는 정적 생성자도 호출이 되었고, (두 번째 Console.ReadLine 덕분에) 다시 windbg로 검사를 해보면,

0:008> !name2ee ConsoleApp1!MyClass
Module:      00007ff916485158
Assembly:    ConsoleApp1.exe
Token:       0000000002000003
MethodTable: 00007ff916485b20
EEClass:     00007ff916482868
Name:        MyClass

이렇게 타입 정보가 로드된 것을 확인할 수 있습니다. 그리고 Age와 Name 필드의 값은 !dumpclass 명령어로 확인할 수 있습니다.

0:008> !dumpclass 00007ff916482868
Class Name:      MyClass
mdToken:         0000000002000003
File:            C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\ConsoleApp1.exe
Parent Class:    00007ff9739d2f68
Module:          00007ff916485158
Method Table:    00007ff916485b20
Vtable Slots:    4
Total Method Slots:  6
Class Attributes:    100001  
Transparency:        Critical
NumInstanceFields:   0
NumStaticFields:     2
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff9739f85a0  4000001       3c         System.Int32  1   static                5 Age
00007ff9739f59c0  4000002        8        System.String  0   static 00000000024a77c8 Name

보는 바와 같이 Age == 5, Name == 00000000024a77c8로 Age의 경우 값 타입이므로 그 값을 그대로 들고 있으며, Name의 경우에는 참조 타입이므로 (string 데이터 자체는 GC Heap에 담겨 있지만) 데이터가 위치한 GC Heap의 주솟값을 들고 있게 됩니다.




그런데, 저걸 보고 왜? static 필드 값이 GC Heap에 보관돼 있지 않다고 말할 수 있는 걸까요?

이것은, GC Heap의 주소 영역을 덤프해 보면 알 수 있습니다.

windbg로 살펴보는 GC heap의 Segment 구조
; https://www.sysnet.pe.kr/2/0/11446

0:008> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00000000024a1030
generation 1 starts at 0x00000000024a1018
generation 2 starts at 0x00000000024a1000
ephemeral segment allocation context: none
         segment             begin         allocated              size
00000000024a0000  00000000024a1000  00000000024a7fe8  0x6fe8(28648)
Large object heap starts at 0x00000000124a1000
         segment             begin         allocated              size
00000000124a0000  00000000124a1000  00000000124a9a90  0x8a90(35472)
Total Size:              Size: 0xfa78 (64120) bytes.
------------------------------
GC Heap Size:            Size: 0xfa78 (64120) bytes.

보는 바와 같이 Age 필드의 주솟값은 저 GC Heap의 SOH, LOH 어느 힙에도 속해 있지 않습니다. 반면, MyClass의 Name 필드가 담고 있는 00000000024a77c8 주솟값은 SOH 세그먼트 영역(00000000024a0000 ~ 00000000024a7fe8) 안을 가리키고 있습니다. (즉, string 데이터 자체는 GC Heap에 담겨 있습니다.)

또한 이것은 (당연하겠지만) 스레드의 stack 영역도 아닙니다.

0:000> ? @rsp
Evaluate expression: 5499480 = 00000000`0053ea58




그런데, 위의 결과에서 이상한 점이 있습니다. 저는 지금까지, static 필드의 값이 EEClass나 MethodTable 정보 영역에 보관돼 있다고 짐작하고 있었는데 이번 실습을 하면서 그 가정이 깨졌습니다.

위에서 실습한 대로, !dumpclass의 출력 결과에 보면 분명히 "Offset" 값이 있는데 Age 필드의 주솟값을 기준으로 역추적해 보면,

0:008> ? 0x7ff9164857ec - 0x3c
Evaluate expression: 140707797424048 = 00007ff9`164857b0

나오는 이 영역이 이상합니다. 다른 출력 결과와 비교해도 분명히 MethodTable도 아니고, EEClass도 아닙니다. 게다가 더 이상한 건, Name 필드에 대한 offset 값이 0x08이고 담고 있는 값이 00000000024a77c8이므로 00007ff9`164857b0 주솟값에서 +08 위치에는 값이 보여야 하는데, 00007ff9`164857b0 앞/뒤로 덤프한 결과에는 해당 값이 나타나지 않았습니다.

00007ff9`16485678 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485690 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`164856a8 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`164856c0 164857b8 00007ff9 00000001 00000000 16485798 00007ff9
00007ff9`164856d8 00000000 00000000 00000003 00000001 00000000 00000038
00007ff9`164856f0 0000001b 00000000 00000000 00000000 00000000 00000000
00007ff9`16485708 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485720 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485738 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485750 00000000 00000000 00000000 00000000 164826e8 00007ff9
00007ff9`16485768 00000001 00000000 00000000 00000000 00772110 00000000
00007ff9`16485780 00000001 00000000 00000000 00000000 00000000 00000000
00007ff9`16485798 00000000 00000033 00000000 00000033 00000000 00000034
00007ff9`164857b0 00000008 00000038 007946c0 00000000 00000000 00000000
00007ff9`164857c8 00000000 00000000 00000000 00000000 124a5ae8 00000000
00007ff9`164857e0 00000001 00000000 00050000 00000005 76305b88 00007ff9
00007ff9`164857f8 00000001 00000000 164858e0 00007ff9 00000000 00000000
00007ff9`16485810 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485828 164858d0 00007ff9 00776d40 00000000 00000000 00000000
00007ff9`16485840 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485858 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`16485870 00000000 00000000 00000000 00000000 00737230 00000000
00007ff9`16485888 00000000 00000000 00000000 00000000 00000000 00000000
00007ff9`164858a0 00000004 00000000 00000000 00000000 007945a0 00000000
00007ff9`164858b8 007946c0 00000000 00000000 00000000 00000000 00000000
00007ff9`164858d0 736e6f43 41656c6f 00317070 00000000 00000000 00000000
00007ff9`164858e8 00000000 00000000 124a5af0 00000000 00000000 00000000
00007ff9`16485900 76305b88 00007ff9 00000004 00000000 16485a00 00007ff9

그러니까... 아마도 저 offset 값이 static 필드의 값을 담고 있는 주솟값에 대한 의미는 아닌 듯합니다. 가만 생각해 보면 static 필드는 AppDomain 별로 분리되므로 전역적으로 단일 저장소에 있다고도 볼 수 없습니다. 다행히 이와 관련해 검색해 보면 다음과 같은 훌륭한 글이 나옵니다. ^^

RVA Static Fields
; https://iobservable.net/blog/2013/03/03/rva-static-fields/

언제 기회 되면 저 글을 보면서 offset 값의 의미를 파악해봐야겠습니다. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/29/2020]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2021-04-01 12시50분
[j] static은 high frequency heap에 저장되는걸로 알고 있어요!
[guest]
2021-04-01 02시21분
@j 님 감사합니다. ^^ 덕분에 알게 되었습니다.

---------------------------------------------------------


using System;

class Program
{
    static int g_i = 0x55;

    static unsafe void Main(string[] args)
    {
        var i = new Program();

        fixed (int* ptr = &g_i)
        {
            Console.WriteLine(new IntPtr(ptr).ToInt64().ToString("x"));
        }

        Console.ReadLine();
    }
}

/* 출력 결과
7ffa781547d4
*/

0:000> !eeheap
Loader Heap:
--------------------------------------
...[생략]...
Domain 1: 0000026379808250
LowFrequencyHeap: 00007ffa78150000(3000:3000) Size: 0x3000 (12288) bytes.
HighFrequencyHeap: 00007ffa78153000(a000:3000) Size: 0x3000 (12288) bytes.
StubHeap: Size: 0x0 (0) bytes.
Virtual Call Stub Heap:
  IndcellHeap: Size: 0x0 (0) bytes.
  LookupHeap: Size: 0x0 (0) bytes.
  ResolveHeap: Size: 0x0 (0) bytes.
  DispatchHeap: Size: 0x0 (0) bytes.
  CacheEntryHeap: Size: 0x0 (0) bytes.
Total size: Size: 0x6000 (24576) bytes.
...[생략]...
정성태
2021-04-01 02시55분
[j] 오,, 상세한 분석 감사합니다!
[guest]

... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...
NoWriterDateCnt.TitleFile(s)
11822정성태2/20/201911636오류 유형: 517. docker에 설치한 MongoDB 서버로 연결이 안 되는 경우
11821정성태2/20/201912090오류 유형: 516. Visual Studio 2019 - This extension uses deprecated APIs and is at risk of not functioning in a future VS update. [1]
11820정성태2/20/201915235오류 유형: 515. 윈도우 10 1809 업데이트 후 "User Profiles Service" 1534 경고 발생
11819정성태2/20/201913906Windows: 158. 컴퓨터와 사용자의 SID(security identifier) 확인 방법
11818정성태2/20/201912831VS.NET IDE: 131. Visual Studio 2019 Preview의 닷넷 프로젝트 빌드가 20초 이상 걸리는 경우 [2]
11817정성태2/17/20199988오류 유형: 514. WinDbg Preview 실행 오류 - Error : DbgX.dll : WindowsDebugger.WindowsDebuggerException: Could not load dbgeng.dll
11816정성태2/17/201912490Windows: 157. 윈도우 스토어 앱(Microsoft Store App)을 명령행에서 직접 실행하는 방법
11815정성태2/14/201911385오류 유형: 513. Visual Studio 2019 - VSIX 설치 시 "The extension cannot be installed to this product due to prerequisites that cannot be resolved." 오류 발생
11814정성태2/12/201910203오류 유형: 512. VM(가상 머신)의 NT 서비스들이 자동 시작되지 않는 문제
11813정성태2/12/201911808.NET Framework: 809. C# - ("Save File Dialog" 등의) 대화 창에 확장 속성을 보이는 방법
11812정성태2/11/20199631오류 유형: 511. Windows Server 2003 VM 부팅 후 로그인 시점에 0xC0000005 BSOD 발생
11811정성태2/11/201913418오류 유형: 510. 서버 운영체제에 NVIDIA GeForce Experience 실행 시 wlanapi.dll 누락 문제
11810정성태2/11/201911485.NET Framework: 808. .NET Profiler - GAC 모듈에서 GAC 비-등록 모듈을 참조하는 경우의 문제
11809정성태2/11/201912995.NET Framework: 807. ClrMD를 이용해 메모리 덤프 파일로부터 특정 인스턴스를 참조하고 있는 소유자 확인
11808정성태2/8/201914051디버깅 기술: 123. windbg - 닷넷 응용 프로그램의 메모리 누수 분석
11807정성태1/29/201912360Windows: 156. 가상 디스크의 용량을 복구 파티션으로 인해 늘리지 못하는 경우 [4]
11806정성태1/29/201912111디버깅 기술: 122. windbg - 덤프 파일로부터 PID와 환경 변수 등의 정보를 구하는 방법
11805정성태1/28/201913959.NET Framework: 806. C# - int []와 object []의 차이로 이해하는 제네릭의 필요성 [4]파일 다운로드1
11804정성태1/24/201912005Windows: 155. diskpart - remove letter 이후 재부팅 시 다시 드라이브 문자가 할당되는 경우
11803정성태1/10/201911488디버깅 기술: 121. windbg - 닷넷 Finalizer 스레드가 멈춰있는 현상
11802정성태1/7/201912873.NET Framework: 805. 두 개의 윈도우를 각각 실행하는 방법(Windows Forms, WPF)파일 다운로드1
11801정성태1/1/201913912개발 환경 구성: 427. Netsh의 네트워크 모니터링 기능 [3]
11800정성태12/28/201813195오류 유형: 509. WCF 호출 오류 메시지 - System.ServiceModel.CommunicationException: Internal Server Error
11799정성태12/19/201813993.NET Framework: 804. WPF(또는 WinForm)에서 UWP UI 구성 요소 사용하는 방법 [3]파일 다운로드1
11798정성태12/19/201813227개발 환경 구성: 426. vcpkg - "Building vcpkg.exe failed. Please ensure you have installed Visual Studio with the Desktop C++ workload and the Windows SDK for Desktop C++"
11797정성태12/19/201810582개발 환경 구성: 425. vcpkg - CMake Error: Problem with archive_write_header(): Can't create '' 빌드 오류
... 61  62  63  64  65  66  67  68  69  70  71  72  [73]  74  75  ...