В настоящее время я проверяю глубокие объекты в CLR с помощью Profiler API. У меня есть конкретная проблема с анализом «этого» аргумента для итераторов/асинхронных методов (сгенерированных компилятором в форме <name>d__123::MoveNext).
Исследуя это, я обнаружил, что действительно существует особое поведение. Во-первых, компилятор C# компилирует эти сгенерированные методы как структуры (только в режиме Release). ECMA-334 (Спецификация языка C#, 5-е издание: https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-334.pdf) говорится (12.7.8 Этот доступ):
"... Если метод или метод доступа является итератором или асинхронной функцией, эта переменная представляет собой копию структуры, для которой был вызван метод или метод доступа,...."
Это означает, что в отличие от других аргументов «this», в данном случае «this» отправляется по значению, а не по ссылке. Я действительно вижу, что копия не изменена снаружи. Я пытаюсь понять, как именно отправляется структура.
Я взял на себя смелость разобрать сложный случай и воспроизвести его с помощью небольшой структуры. Посмотрите на следующий код:
struct Struct
{
public static void mainFoo()
{
Struct st = new Struct();
st.a = "String";
st.p = new Program();
System.Console.WriteLine("foo: " + st.foo1());
System.Console.WriteLine("static foo: " + Struct.foo(st));
}
int i;
String a;
Program p;
[MethodImplAttribute(MethodImplOptions.NoInlining)]
public static int foo(Struct st)
{
return st.i;
}
[MethodImplAttribute(MethodImplOptions.NoInlining)]
public int foo1()
{
return i;
}
}
NoInlining просто для того, чтобы мы могли правильно проверить JIT-код. Я смотрю на три разные вещи: как mainFoo вызывает foo/foo1, как компилируется foo и как компилируется foo1. Ниже приведен сгенерированный код IL (с использованием ildasm):
.method public hidebysig static int32 foo(valuetype nitzan_multi_tester.Struct st) cil managed noinlining
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: ldfld int32 nitzan_multi_tester.Struct::i
IL_0006: ret
} // end of method Struct::foo
.method public hidebysig instance int32 foo1() cil managed noinlining
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: ldfld int32 nitzan_multi_tester.Struct::i
IL_0006: ret
} // end of method Struct::foo1
.method public hidebysig static void mainFoo() cil managed
{
// Code size 86 (0x56)
.maxstack 2
.locals init ([0] valuetype nitzan_multi_tester.Struct st)
IL_0000: ldloca.s st
IL_0002: initobj nitzan_multi_tester.Struct
IL_0008: ldloca.s st
IL_000a: ldstr "String"
IL_000f: stfld string nitzan_multi_tester.Struct::a
IL_0014: ldloca.s st
IL_0016: newobj instance void nitzan_multi_tester.Program::.ctor()
IL_001b: stfld class nitzan_multi_tester.Program nitzan_multi_tester.Struct::p
IL_0020: ldstr "foo: "
IL_0025: ldloca.s st
IL_0027: call instance int32 nitzan_multi_tester.Struct::foo1()
IL_002c: box [mscorlib]System.Int32
IL_0031: call string [mscorlib]System.String::Concat(object,
object)
IL_0036: call void [mscorlib]System.Console::WriteLine(string)
IL_003b: ldstr "static foo: "
IL_0040: ldloc.0
IL_0041: call int32 nitzan_multi_tester.Struct::foo(valuetype nitzan_multi_tester.Struct)
IL_0046: box [mscorlib]System.Int32
IL_004b: call string [mscorlib]System.String::Concat(object,
object)
IL_0050: call void [mscorlib]System.Console::WriteLine(string)
IL_0055: ret
} // end of method Struct::mainFoo
Сгенерированный ассемблерный код (только соответствующие части):
foo/foo1:
mov eax,dword ptr [rcx+10h]
ret
fooMain (line 18):
mov rcx,offset mscorlib_ni+0x8aaf8 (00007ffc`37d6aaf8) (MT: System.Int32)
call clr+0x2510 (00007ffc`392f2510) (JitHelp: CORINFO_HELP_NEWSFAST)
mov rsi,rax
lea rcx,[rsp+40h]
call 00007ffb`d9db04e0 (nitzan_multi_tester.Struct.foo1(), mdToken: 000000000600000b)
mov dword ptr [rsi+8],eax
mov rdx,rsi
mov rcx,1DBCE383690h
mov rcx,qword ptr [rcx]
call mscorlib_ni+0x635bd0 (00007ffc`38315bd0) (System.String.Concat(System.Object, System.Object), mdToken: 000000000600054f)
mov rcx,rax
call mscorlib_ni+0x56d290 (00007ffc`3824d290) (System.Console.WriteLine(System.String), mdToken: 0000000006000b78)
fooMain (line 19):
mov rcx,offset mscorlib_ni+0x8aaf8 (00007ffc`37d6aaf8) (MT: System.Int32)
call clr+0x2510 (00007ffc`392f2510) (JitHelp: CORINFO_HELP_NEWSFAST)
mov rsi,rax
lea rcx,[rsp+28h]
mov rax,qword ptr [rsp+40h]
mov qword ptr [rcx],rax
mov rax,qword ptr [rsp+48h]
mov qword ptr [rcx+8],rax
mov eax,dword ptr [rsp+50h]
mov dword ptr [rcx+10h],eax
lea rcx,[rsp+28h]
call 00007ffb`d9db04d8 (nitzan_multi_tester.Struct.foo(nitzan_multi_tester.Struct), mdToken: 000000000600000a)
mov dword ptr [rsi+8],eax
mov rdx,rsi
mov rcx,1DBCE383698h
mov rcx,qword ptr [rcx]
call mscorlib_ni+0x635bd0 (00007ffc`38315bd0) (System.String.Concat(System.Object, System.Object), mdToken: 000000000600054f)
mov rcx,rax
call mscorlib_ni+0x56d290 (00007ffc`3824d290) (System.Console.WriteLine(System.String), mdToken: 0000000006000b78)
Первое, что мы все видим, это то, что и foo, и foo1 генерируют один и тот же IL-код (и один и тот же JIT-код сборки). Это имеет смысл, поскольку в конечном итоге мы используем только первый аргумент. Второе, что мы видим, это то, что mainFoo вызывает два метода по-разному (ldloc и ldloca). Поскольку и foo, и foo1 ожидают одни и те же входные данные, я ожидаю, что mainFoo отправит одни и те же аргументы. Это вызвало 3 вопроса
1) Что именно означает загрузка структуры в стек по сравнению с загрузкой адреса структуры в этот стек? Я имею в виду, что структура размером более 8 байт (64 бита) не может «сидеть» в стеке.
2) Создает ли CLR копию структуры, прежде чем использовать ее как «эту» (мы знаем, что это правда, согласно спецификации С#)? Где хранится эта копия? Сборка fooMain показывает, что вызывающий метод создает копию в своем стеке.
3) Кажется, что при загрузке структуры по значению и адресу (ldarg/ldloc против ldarga/ldloca) на самом деле загружается адрес - для второго набора он просто создает копию перед этим. Почему? Я что-то упустил здесь?
4) Вернемся к Iterators/async. Воспроизводит ли пример foo/foo1 разницу между «этим» аргументом для структур итераторов и не-итераторов? Почему такое поведение желательно? Создание копии кажется пустой тратой времени. Какова мотивация?
(Этот пример взят с использованием .Net framework 4.5, но такое же поведение наблюдается и с использованием .Net framework 2 и CoreCLR)
