(번역글) .NET Internals Cookbook Part 5 - Methods, parameters, modifiers

이번에도 .NET Internals Cookbook 시리즈의 5번째 글을 번역한 것입니다.

(번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes
; https://www.sysnet.pe.kr/2/0/11838

(번역글) .NET Internals Cookbook Part 2 - GC-related things
; https://www.sysnet.pe.kr/2/0/11869

(번역글) .NET Internals Cookbook Part 3 - Initialization tricks
; https://www.sysnet.pe.kr/2/0/11871

(번역글) .NET Internals Cookbook Part 4 - Type members
; https://www.sysnet.pe.kr/2/0/11872

.NET Internals Cookbook Part 5 - Methods, parameters, modifiers
; https://blog.adamfurmanek.pl/2019/03/16/net-internals-cookbook-part-5/

(번역글) .NET Internals Cookbook Part 6 - Object internals
; https://www.sysnet.pe.kr/2/0/11874

(번역글) .NET Internals Cookbook Part 7 - Word tearing, locking and others
; https://www.sysnet.pe.kr/2/0/11876

(번역글) .NET Internals Cookbook Part 8 - C# gotchas
; https://www.sysnet.pe.kr/2/0/11877

(번역글) .NET Internals Cookbook Part 9 - Finalizers, queues, card tables and other GC stuff
; https://www.sysnet.pe.kr/2/0/11878

(번역글) .NET Internals Cookbook Part 10 - Threads, Tasks, asynchronous code and others
; https://www.sysnet.pe.kr/2/0/11879

(번역글) .NET Internals Cookbook Part 11 - Various C# riddles
; https://www.sysnet.pe.kr/2/0/11882

(번역글) .NET Internals Cookbook Part 12 - Memory structure, attributes, handles
; https://www.sysnet.pe.kr/2/0/11891

---

C#으로는 가능하지 않지만,

public class MyClass
{
    public int GetValue()
    {
        return 5;
    }

    // 컴파일 에러
    // error CS0111: Type 'MyClass' already defines a member called 'GetValue' with the same parameter types
    public string GetValue()
    {
        return "TEST";
    }
}

IL 코드로는 가능합니다.

.class public auto ansi beforefieldinit MyClass
       extends [mscorlib]System.Object
{
  .method public hidebysig instance int32 GetValue() cil managed
  {
    // Code size       7 (0x7)
    .maxstack  1
    .locals init ([0] int32 V_0)
    IL_0000:  nop
    IL_0001:  ldc.i4.5
    IL_0002:  stloc.0
    IL_0003:  br.s       IL_0005

    IL_0005:  ldloc.0
    IL_0006:  ret
  } // end of method MyClass::GetValue

  .method public hidebysig instance string GetValue() cil managed
  {
    // Code size       11 (0xb)
    .maxstack  1
    .locals init ([0] string V_0)
    IL_0000:  nop
    IL_0001:  ldstr      "TEST"
    IL_0006:  stloc.0
    IL_0007:  br.s       IL_0009

    IL_0009:  ldloc.0
    IL_000a:  ret
  } // end of method MyClass::GetValue

  ...[생략]...

} // end of class MyClass

하지만, 이렇게 만든 클래스를 포함한 DLL을 C# 프로젝트에서 참조해 사용하면 GetValue 메서드 호출에서 모호함 오류가 발생합니다.

class Program
{
    static void Main(string[] args)
    {
        MyClass mc = new MyClass();

        int n = mc.GetValue(); // 컴파일 오류: The call is ambiguous between the following methods or properties: 'MyClass.GetValue()' and 'MyClass.GetValue()'

        string txt = mc.GetValue(); // 컴파일 오류: The call is ambiguous between the following methods or properties: 'MyClass.GetValue()' and 'MyClass.GetValue()'
    }
}

즉, 호출하는 측도 동일하게 IL 코드로 작성해야만 하는 것입니다.

IL_0001:  call       int32 Program::Foo()
IL_0006:  stloc.0
IL_0007:  call       float64 Program::Foo()

---

가령 다음과 같은 코드가 있을 때,

using System;

public class Program
{
    const int a = 5;
    static readonly int b = 6;

    public static void Main()
    {
        Foo(a);
        Foo(b);
    }
    
    static void Foo(int x){
        Console.WriteLine(x);
    }
}

const 변수를 사용하는 측에서는 값 자체가 치환되는 반면, readonly의 경우에는 필드를 다루는 코드가 됩니다. 확인을 위해, 위에서 Foo 호출 부분의 IL 코드를 보면,

IL_0001:  ldc.i4.5
IL_0002:  call       void Program::Foo(int32)
IL_0007:  nop
IL_0008:  ldsfld     int32 Program::b
IL_000d:  call       void Program::Foo(int32)

보는 바와 같이 const의 경우 숫자 5를 직접 사용하는 반면, readonly의 경우에는 ldsfld IL 명령어를 이용해 b 필드를 로드하는 식으로 동작합니다.

이런 특성으로 인해 주의해야 할 시나리오가, const를 갖는 라이브러리를 참조해 사용한 어셈블리들이 있는 경우 라이브러리 측의 const 값을 바꾸면 그것을 사용하는 다른 어셈블리들도 반드시 재빌드해야 한다는 것입니다. 따라서, const 필드는 향후 변경 가능한 값이라면 사용하지 않거나, 같은 어셈블리 내에서만 가능하도록 public 접근자는 지정하지 않는 것이 좋습니다.

---

이 부분은 제 책의 "4.5.1.5 구조체"에서 설명한 "깊은 복사와 얕은 복사"를 참조하세요. ^^

---

물론 대부분의 경우 단순히 메서드에서 정의한 인자의 순서와 일치할 것이므로 그 순서가 크게 중요하지 않을 수 있는데요. 간혹 "명명된 인수" 방식으로 지정하는 경우라면 메서드에서 정의한 순서와 일치하지 않을 수 있으므로 혼동이 될 수 있습니다.

using System;

public class Program
{
    public static void Main()
    {
        Foo(b: Identity(5), a: Identity(4));
    }
    
    static void Foo(int a, int b){
        Console.WriteLine($"a = {a}\nb = {b}");
    }
    
    static int Identity(int x){
        Console.WriteLine(x);
        return x;
    }}
}

/* 출력 결과
5
4
a = 4
b = 5
*/

보는 바와 같이, 인자의 식 평가 순서는 메서드의 인자 순서가 아니라 호출 측에서의 순서를 따릅니다.

---

코드 먼저 보면,

using System;

public class Program
{
    public static void Main()
    {
        Type t = typeof(Foo);
        Type u = new Foo().GetType();
    }
}

class Foo{
    public Foo(){
        Console.WriteLine("Constructor!");
    }
}

빌드 후 IL 코드 결과는 다음과 같습니다.

// typeof(Foo)
IL_0001:  ldtoken    Foo
IL_0006:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)

// new Foo().GetType()
IL_000c:  newobj     instance void Foo::.ctor()
IL_0011:  call       instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()

원 글(.NET Internals Cookbook Part 5 - Methods, parameters, modifiers)에서는 typeof는 컴파일 시점에, GetType은 실행 시점에 평가된다고 하는데, 개인적인 의견으로는 그다지 좋은 설명 같지는 않습니다. 액면 그대로, typeof는 타입명을 요구하고, GetType은 System.Object로부터 상속받은 인스턴스 메서드이므로 객체를 요구한다는 차이로 보면 될 것 같습니다.

---

우선 using 먼저 볼까요?

using System;

public class Program
{
    public static void Main()
    {
        using(new Foo()){
            // ...
        }
    }
}
            
class Foo : IDisposable {
    public void Dispose(){}
}

C# 컴파일러는 위의 using 문을 다음과 같이 변환해 컴파일합니다.

public static void Main()
{
    Foo objUsing = new Foo();

    try
    {
        // ...
    }
    finally
    {
        if (objUsing != null)
        {
            objUsing.Dispose();
        }
    }
}

이번엔 lock을 보겠습니다.

public static void Main()
{
    lock (new object())
    {
        // ...
    }
}

위의 코드는 C# 컴파일러가 다음과 같은 처리를 합니다.

public static void Main()
{
    object objLock = new object();
    bool lockTaken = false;

    try
    {
        Monitor.Enter(objLock, ref lockTaken);
        // ...
    }
    finally
    {
        if (lockTaken == true)
        {
            Monitor.Exit(objLock);
        }
    }
}

위의 처리는 C# 4.0부터 적용되며 3.5 이전 버전에는 다음과 같은 식으로 처리가 되었습니다.

public static void Main()
{
    object objLock = new object();
    Monitor.Enter(objLock);

    try
    {
        // ...
    }
    finally
    {
        Monitor.Exit(objLock);
    }
}

위에서 Monitor.Enter가 try 블록 이전에 수행되었다는 것을 눈여겨볼 필요가 있습니다. 따라서 Monitor.Enter 실행 후, ThreadAbortException이 발생해 해당 스레드가 종료되는 경우 영원히 lock이 풀리지 않는 문제가 발생하는 버그를 유발할 수 있었습니다. (참고: Subtleties of C# IL codegen)

---

호출 규약이 난립해 있던 x86의 경우, .NET 메서드는 __clrcall 호출 규약을 따릅니다. 이것은 __fastcall 호출 규약과 같지만 단지 인자의 전달 순서만 좌측에서 우측이라는 점만 다릅니다.

예를 들어 다음의 코드는,

using System;

public class Program
{
    public static void Main()
    {
        Static(1, 2, 3, 4, 5, 6);
        new Program().Instance(1, 2, 3, 4, 5, 6);
    }

    public static void Static(int a, int b, int c, int d, int e, int f)
    {
    }

    public void Instance(int a, int b, int c, int d, int e, int f)
    {
    }
}

Static 메서드 호출은 다음과 같이 인자 처리가 되며,

push    3
push    4
push    5
push    6
mov     ecx,1
mov     edx,2

Instance 메서드 호출은 이렇게 됩니다.

push    2
push    3
push    4
push    5
push    6
mov     ecx,dword ptr [ebp-4] // this 포인터
mov     edx,1

반면 x64에서는 모든 호출 규약이 Microsoft x64로 단일하게 바뀌었으므로 Static과 Instance 메서드 호출의 인자 전달은 this 포인터 처리를 제외하고 동일한 구조를 가집니다.

// Static 메서드 호출 인자 처리
mov     dword ptr [rsp+20h],5
mov     dword ptr [rsp+28h],6
mov     ecx,1
mov     edx,2
mov     r8d,3
mov     r9d,4

// Instance 메서드 호출 인자 처리
mov     dword ptr [rsp+20h],4
mov     dword ptr [rsp+28h],5
mov     dword ptr [rsp+30h],6
mov     rcx,qword ptr [rbp-8] // this 포인터
mov     edx,1
mov     r8d,2
mov     r9d,3

---

원칙은 const 변수를 초기화하는 값이 컴파일 시에 결정되는 상수식이라면 가능합니다. 하지만 사용자 정의 타입인 경우 참조 형식(class)이라면 null 초기화만 가능한 반면 값 형식(struct)의 경우에는 기본 자료형을 제외하고는 모든 구조체가 const 초기화를 할 수 없습니다.

그런데, 한가지 재미있는 점이라면 decimal의 const 처리 방식이 독특하다는 점입니다.

using System;

public class Program
{
    const decimal a = 5;
    const string b = "abc";
    const Foo c = null;

    public static void Main()
    {
    }
}

class Foo { }

위의 코드에 대해 각각의 const 변수를 IL 코드로 확인해 보면,

.field private static initonly valuetype [mscorlib]System.Decimal a
.field private static literal string b = "abc"
.field private static literal class Foo c = nullref

System.Decimal의 경우 literal이 아닌, initonly로 처리되어 실제적인 값의 초기화는 (인스턴스 생성자가 아닌) static 생성자에서 이뤄지는 것을 볼 수 있습니다.

.method private hidebysig specialname rtspecialname static 
          void  .cctor() cil managed
  {
    // 
    .maxstack  8
    .line 5,5 : 2,22 ''
    IL_0000:  ldc.i4.5
    IL_0001:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32)
    IL_0006:  stsfld     valuetype [mscorlib]System.Decimal Program::a
    IL_000b:  ret
  } // end of method Program::.cctor

그러면서도 C# 컴파일러는 static 생성자에서 const decimal 변수를 초기화하는 코드를 허용하지는 않습니다.

static Program()
{
    a = 6; // 컴파일 에러 - error CS0131: The left-hand side of an assignment must be a variable, property or indexer
}

재미있는 것은, 이런 이유로 인해 decimal의 경우 값이 바뀐다 해도 28번의 내용에서 설명한 재컴파일이 필요하지는 않습니다.

---

전달할 수는 있지만, C# 컴파일러는 컴파일 시점에 경고를 발생시킵니다.

using System;

public class Program
{
    static volatile int a = 5;
    public static void Main()
    {
        // 컴파일 경고
        // warning CS0420: 'Program.a': a reference to a volatile field will not be treated as volatile
        Foo(ref a);
    }

    static void Foo(ref int x)
    {
    }
}

volatile 필드가 참조로 전달된 경우에는 volatile로 다뤄지지 않는다는 것입니다. 즉, Foo 함수의 변수 x에 대해서는 일반 변수와 동일하게 처리된다는 것인데... 하지만 이로 인한 문제가 발생할 수 있는 코드를 재현하기가 쉽지 않습니다. (혹시 적당한 재현 예제를 구현하신 분은 덧글 부탁드립니다. ^^)

(첨부 파일은 이 글의 예제 코드를 포함합니다.)

---

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

[최초 등록일: 4/19/2019]
[최종 수정일: 4/9/2024]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com