CLR JIT 컴파일러가 생성한 기계어 코드 확인하는 방법
우선, 다음의 글을 보실까요?
언제부터 보이지 않는 키워드 for, foreach.
; http://illef.tistory.com/105
질문을 정리해 보면, 아래와 같은 C# 코드에 대해 JIT 컴파일러가 최적화를 했는지 안했는지를 알 수 없다는 것입니다. 즉 해당 코드들이 실행을 하는지 안하는지 모르겠다는 것인데요.
for(int i=0;i<10;i++){}
물론, 디버거를 이용하면 기계어 코드의 생성 여부를 알 수 있습니다. 테스트 삼아서 같이 해볼까요? ^^ 일단, 코드 구성을 다음고 같이 해주고,
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
MyFunc(); // JIT 컴파일이 릴리스 상태에서 최적화되어
// 발생하도록 한 번 호출해 줍니다.
Console.WriteLine("Press any key to continue...");
Console.ReadLine();
MyFunc();
}
private static void MyFunc()
{
Console.WriteLine("...");
for (int i = 0; i < 10; i++) { }
}
}
}
"Control + F5" 키를 이용해서 디버깅 없이 그냥 실행시킵니다. 그럼, 콘솔 프로그램이 뜨게 되고 두 번째 MyFunc 메서드 실행 전에 멈추게 되는데, 이 때 Visual Studio의 "Debug" / "Attach to Process..." 메뉴를 실행시켜서 해당 EXE 파일을 "Managed (v4.0) code, Native code" 모드로 연결합니다. (왜 Native까지 필요할까요?)
닷넷 어셈블리가 정상적으로 Release 모드로 빌드되었고 JIT 컴파일러에 의해 최적화가 된 상태라면 다음과 같은 대화창이 뜹니다. (이 대화창이 나타나지 않았다면 Debug 모드로 구동되었거나, 최적화 진행이 안되고 있는 것입니다.)
현재 상황에서는 이것이 의도했던 바이기 때문에 무시하고 넘어갑니다. 디버거가 정상적으로 연결되었으면, "Ctrl + Alt + Break (Break All)" 키를 눌러 디버기(Debugee)의 실행을 멈춥니다.
이제, "Ctrl + D, I" 키를 눌러서 "Immediate Window"를 띄우고 다음과 같이 SOS 확장을 로드합니다. (Native 모드로 연결해야만 sos.dll 확장을 이용할 수 있습니다.)
.load sos
extension C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll loaded
SOS를 이용해서 다음과 같이 MyFunc을 찾고,
!name2ee ConsoleApplication1.exe ConsoleApplication1.Program.MyFunc
Module: 00192e9c
Assembly: ConsoleApplication1.exe
Token: 395550f606000002
MethodDesc: 001933fc
Name: ConsoleApplication1.Program.MyFunc()
JITTED Code Address: 002300c0
이렇게 기계어로 컴파일된 주소까지 얻었으니 게임 끝이군요.
!u 002300c0
Normal JIT generated code
ConsoleApplication1.Program.MyFunc()
Begin 002300c0, size 1a
>>> 002300C0 55 push ebp
002300C1 8BEC mov ebp,esp
002300C3 E808704060 call 606370D0 (System.Console.get_Out(), mdToken: 060008cd)
002300C8 8BC8 mov ecx,eax
002300CA 8B1534207F03 mov edx,dword ptr ds:[037F2034h] ("...")
002300D0 8B01 mov eax,dword ptr [ecx]
002300D2 8B403C mov eax,dword ptr [eax+3Ch]
002300D5 FF5010 call dword ptr [eax+10h]
002300D8 5D pop ebp
002300D9 C3 ret
위에 보는 것처럼, System.Console.WriteLine 메서드에 대한 call을 제외하고 for 문에 대한 어떠한 기계어 코드도 생성되지 않았기 때문에 최적화 과정에서 쓸모없는 for 코드가 제거되었음을 알 수 있습니다.
궁금해 하실 분이 계실 텐데, System.Console.WriteLine의 경우 제가 테스트 결과를 확연히 보기 위해 의도적으로 집어넣은 것입니다. 만약 그 코드를 빼면 MyFunc는 for 문만 포함하게 되고 결국 쓸모없는 메서드가 되어 JIT 컴파일 시에 메서드 자체가 날아가버립니다. 이 때문에, name2ee 명령을 내리면 아래와 같이 아예 JITTED 되지 않았다고 나옵니다. (메서드가 날아가버리는 또 다른 이유는 메서드 내부의 코드가 호출측에 in-line화 되는 경우입니다.)
!name2ee ConsoleApplication1.exe ConsoleApplication1.Program.MyFunc
PDB symbol for clr.dll not loaded
Module: 00192e9c
Assembly: ConsoleApplication1.exe
Token: a86af99b06000002
MethodDesc: 001937fc
Name: ConsoleApplication1.Program.MyFunc()
Not JITTED yet. Use !bpmd -md 001937fc to break on run.
끝마치기 전에!
재미있게도, for 문에 지정된 루프 수를 바꾸면 JIT 컴파일에 포함이 됩니다.
for(int i=0;i<1000;i++){}
.load sos
extension C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll loaded
!name2ee ConsoleApplication1.exe ConsoleApplication1.Program.MyFunc
PDB symbol for clr.dll not loaded
Module: 001e2e9c
Assembly: ConsoleApplication1.exe
Token: 1e71bfd206000002
MethodDesc: 001e37fc
Name: ConsoleApplication1.Program.MyFunc()
JITTED Code Address: 002400c0
!u 002400c0
Normal JIT generated code
ConsoleApplication1.Program.MyFunc()
Begin 002400c0, size f
>>> 002400C0 55 push ebp
002400C1 8BEC mov ebp,esp
002400C3 33C0 xor eax,eax
002400C5 40 inc eax
002400C6 3DE8030000 cmp eax,3E8h
002400CB 7CF8 jl 002400C5
002400CD 5D pop ebp
002400CE C3 ret
마이크로소프트의 공식 입장은 알 수 없지만, 아마도 일정 루프 이상은 일부러 '지연(delay)'시키는 효과를 내기 위한 것이라고 판단하고 기계어 번역을 해주는 것이 아닌가 싶습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]